Ticket #8274 (new defect)

Opened 2 years ago

TracWysiwyg for 0.12 broken with Chrome and Firefox 3.6

Reported by: Assigned to: JoelFoner jun66j5 high TracWysiwygPlugin critical joel.foner@gmail.com, bobbysmith007 0.12

It appears that the WYSIWYG option is not set up properly for the ticket body with Chrome and Firefox 3.6.

Editing in WYSIWYG mode works reasonably in comments, but in the body of the ticket itself, there are two issues:

• styling of the radio buttons places the wysiwyg button in a place where you will often get another item rather than the radio button activation (trivially fixed by user by clicking on the "wysiwyg" text, but a bit of an irritant
• the blocker is that with these two browsers, going into wysiwyg mode disables editing of the ticket body textbox area

Change History

12/06/10 06:42:01 changed by rjollos

• description changed.

12/06/10 06:54:34 changed by jun66j5

Works for me with Trac-0.12.2dev, TracWysiwyg-0.12.0.3-r9387 and Firefox 3.6.12.

1. Which the revision of tracwysiwyg do you use? You should use http://trac-hacks.org/svn/tracwysiwygplugin/0.12 with Trac-0.12.x.
2. Check the javascript console in your browser.

01/12/11 03:07:29 changed by chris.walters@spiderstrategies.com

This is happening for me in FF 3.6.13, FF 4.0b8, and Chrome running Trac 0.12.1. Creating a new ticket, the wysiwyg box is locked, and switching to the textarea radio button and back throws the following

Stacktrace in FireBug:

  selection is null
getNativeSelectionRange() - wysiwyg.js (line 3250)
getSelectionPosition() - wysiwyg.js (line 3344)
selectionChanged() - wysiwyg.js (line 1330)
lazy() - wysiwyg.js (line 735)
[Break On This Error] return selection.rangeCount > 0 ? selection.getRangeAt(0) : null;
wysiwyg.js (line 3250)


01/12/11 16:16:10 changed by chris.walters@spiderstrategies.com

After enabling and disabling other plugins, it seems there is a conflict with the TimingAndEstimationPlugin. This error only happens when the TicketPropsLayoutChanger is enabled.

04/18/11 13:02:32 changed by mwg@mwg.dp.ua

This is also reproducible with package combination listed in #8716 :

Python-2.7.1
Trac-0.12.2-py2.7
TracWysiwyg-0.12.0.3_r9676-py2.7
timingandestimationplugin-1.1.2b-py2.7

Tested with different browsers (Seamonkey, Chrome, Opera, Firefox 3.6&4)

04/18/11 13:04:13 changed by mwg@mwg.dp.ua

• owner changed from jun66j5 to bobbysmith007.
• component changed from TracWysiwygPlugin to TimingAndEstimationPlugin.

04/18/11 15:03:30 changed by bobbysmith007

• cc changed from joel.foner@gmail.com to joel.foner@gmail.com, bobbysmith007.
• owner changed from bobbysmith007 to jun66j5.
• component changed from TimingAndEstimationPlugin to TracWysiwygPlugin.

Well I wasnt able to track down why the error only occurs when the TicketPropsLayoutChanger? is enabled, but by changing the getNativeSelectionRange js function I was able to prevent the "disabled" component bug (javascript errors).

Index: tracwysiwyg/htdocs/wysiwyg.js
===================================================================
--- tracwysiwyg/htdocs/wysiwyg.js       (revision 9972)
+++ tracwysiwyg/htdocs/wysiwyg.js       (working copy)
@@ -3247,7 +3247,7 @@
};
TracWysiwyg.prototype.getNativeSelectionRange = function() {
var selection = this.contentWindow.getSelection();
-            return selection.rangeCount > 0 ? selection.getRangeAt(0) : null;
+            return selection && selection.rangeCount > 0 ? selection.getRangeAt(0) : null;
};
TracWysiwyg.prototype.expandSelectionToElement = function(arg) {
if (arg.start || arg.end) {


The TicketPropsLayoutChanger? just removes/compacts empty table cells and rows out of the ticket properties tables (I didnt write it, and its not super well commented, but reading through, it seems correctish and has been working till now). It also doesnt seem to affect the description box other than to remove it and re-add it to the dom. I am not sure what it is using selection for, or why the selection would be null in some browsers after affecting the dom, so i cannot speculate on if this fix is "correct", only that it seems to fix the most obvious and immediate bug.

Please let me know if you need further help with this. I believe the style bug is related to default font widths, but I think the solution probably involves float boundaries. Either way the style bug seems unrelated to T&E

Cheers, Russ

06/08/11 14:18:43 changed by anonymous

I'm having problems with TracWysiwyg? for 0.11 in Chrome and Firefox as well. It seems to be related to a problem while loading jquery, since I'm getting a 404 error when trying to GET jquery.js.

06/08/11 14:29:03 changed by anonymous

I just solved the problem by copying jquery.js into /usr/lib/python2.6/dist-packages/trac/htdocs/js and it seems to be working properly so far.

07/01/11 06:03:48 changed by mattwhite

I was able to fix the conflict with the Timing and Estimation plugin by making a quick edit to its whitespace_remover.js file. This of course means that if both plugins are enabled, there may be some extra whitespace in the Modify Ticket table, but at least the wysiwyg editor works.

timingandestimationplugin/htdocs/whitespace_remover.js
49c50
<      $('#properties table').cleanupTable(); --- > if ($('#properties table').find('iframe.wysiwyg').length == 0) \$('#properties table').cleanupTable();


Add/Change #8274 (TracWysiwyg for 0.12 broken with Chrome and Firefox 3.6)

Change Properties