TracWysiwyg for 0.12 broken with Chrome and Firefox 3.6

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.

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)

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

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)

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

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.

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.

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();