Plugin no longer works correctly when used with the wysiwyg plugin

@reporter: A screen capture would be useful.

Looks like this should be assigned against the TracWysiwygPlugin.

I second this bug. Based on looking at how the WYSIWYG plugin works it seems to me that this needs to be changed on the TimingAndEstimation? Plugin side. It is because the WYSIWYG plugin "disables" the div that contains the original text box which has the Add Hours attached to it and "enables" an other div that contains the WYSIWYG editor text box. Because of this the Add Hours entry fields are not visible. So it seems that the only solution is to separate the Comment text box and the Add hours fields hence the WYSIWYG operation will have no effects on it.

I'm attaching the requested screen shots.

Also, there is something funky going with the TicketPropsLayoutChanger? as described here: http://trac-hacks.org/ticket/8274

Screenshot of TimingAndEstimate? Add Hours With TextArea?

Screenshot of TimingAndEstimate? Add Hours With WYSIWYG

Replying to kmolnar@virtualorgs.com:

I second this bug. Based on looking at how the WYSIWYG plugin works it seems to me that this needs to be changed on the TimingAndEstimation? Plugin side. It is because the WYSIWYG plugin "disables" the div that contains the original text box which has the Add Hours attached to it and "enables" an other div that contains the WYSIWYG editor text box. Because of this the Add Hours entry fields are not visible. So it seems that the only solution is to separate the Comment text box and the Add hours fields hence the WYSIWYG operation will have no effects on it.

Alternatively WYSIWYG, could not replace the entire div, but the textarea itself. It seems that this would interfere much less with every other plugin (not just TimingAndEstimationPlugin). That said, I will try to append this field elsewhere, so that T&E is no longer blamable.

(In [9973]) Changed where the add-hours field is being moved to (not visibly) to increase interoperability ver 1.1.1 fix #8314

Tested with the 1.1.1 version and the problem is gone. Thank you very much for the prompt response and fix.

Your welcome, glad to be of assistance :)

That problem - T&E conflict with TracWysiwygPlugin retback again. For me from T&E v.1.2.4 and Trac 0.12.2. When in T&E plugin config I set to true checkbox "TimingEstimationAndBillingPage?" - I can't use TracWysiwygPlugin when create new ticket in that trac. In that situation we're can't edit via TracWysiwygPlugin ticket's body. :(

sorry - I forgot one thing: also that problem stotred till v.1.2.7 T&E plugin (till current version).

With T&E disabled Wysiwyg seems to work but throws many javascript errors like:

uncaught exception: TypeError: event.originalTarget.getElementsByTagName is not a function
[Break On This Error] 	
return this.contentDocument.execCommand(name, false, arg); wysiwyg.js (line 569)


uncaught exception: TypeError: event.originalTarget.getElementsByTagName is not a function

The bug I am capable of reproducing comes about when enabling TicketPropsLayoutChanger. This component is not vital and can safely be turned off. (It simply tries to remove some empty rows that occasionally show up in the ticket properties.

When enabled that component prevents the wysiwyg box from being enabled for typing, though why I am not sure. Please try disabling TicketPropsLayoutChanger and verify that everything works as you would expect. Not sure what to do about this as I have had little luck figuring out what is causing the problem.

It's works for me, thank you sir!

I guess resolving this as fixed. It would be swell if someone posted a patch that didnt require removing one of the components for these to be compatible, but honestly this is such a non priority for me that I doubt I will ever accomplish this.

I changed all the layout changing javascript in #10977, perhaps this problem is solved now?