Plugin no longer works correctly when used with the wysiwyg plugin

[anonymous]

Since the timing and estimation plugin was updated to put the 'Add hours to ticket' field just below the comment field (and above the 'Modify Ticket' section), the field becomes invisible when the wysiwyg comment editor is selected.

To reproduce: Install trac 0.12, with timing and estimation tools plugin for 0.12 (I am using an export from svn rev 9643), and wysiwyg plugin for 0.12 (I am using an export from svn rev 9251). Enable both plugins in a project. Now choose the "wysiwyg" radio button just below the "Add a comment" header. When selecting "wysiwyg", you should see the "Add hours to ticket" field and stopwatch disappear. Selecting "textarea" should make those fields re-appear.

[Ryan J Ollos]

@reporter: A screen capture would be useful.

Looks like this should be assigned against the TracWysiwygPlugin.

[kmolnar@…]

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

[kmolnar@…]

Screenshot of TimingAndEstimate Add Hours With TextArea

[kmolnar@…]

Screenshot of TimingAndEstimate Add Hours With WYSIWYG

[Russ Tyndall]

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.

[Russ Tyndall]

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

[kmolnar@…]

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

[Russ Tyndall]

Your welcome, glad to be of assistance :)

[slevin@…]

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. :(

[slevin@…]

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

[Russ Tyndall]

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.

[slevin@…]

It's works for me, thank you sir!

[Russ Tyndall]

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.

[Russ Tyndall]

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