Opened 6 years ago

Closed 2 years ago

#8274 closed defect (wontfix)

TracWysiwyg for 0.12 broken with Chrome and Firefox 3.6

Reported by: JoelFoner Owned by: jun66j5
Priority: high Component: TracWysiwygPlugin
Severity: critical Keywords:
Cc: JoelFoner, bobbysmith007 Trac Release: 0.12

Description (last modified by rjollos)

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

Attachments (1)

screenshot-1.png (26.6 KB) - added by jun66j5 6 years ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 6 years ago by rjollos

  • Description modified (diff)

Changed 6 years ago by jun66j5

comment:2 Changed 6 years ago by jun66j5

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

  1. Which the revision of tracwysiwyg do you use? You should use with Trac-0.12.x.
  2. Check the javascript console in your browser.

comment:3 Changed 6 years ago by chris.walters@…

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)

comment:4 Changed 6 years ago by chris.walters@…

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

comment:5 Changed 6 years ago by mwg@…

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


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

comment:6 Changed 6 years ago by mwg@…

  • Component changed from TracWysiwygPlugin to TimingAndEstimationPlugin
  • Owner changed from jun66j5 to bobbysmith007

comment:7 Changed 6 years ago by bobbysmith007

  • Cc bobbysmith007 added
  • Component changed from TimingAndEstimationPlugin to TracWysiwygPlugin
  • Owner changed from bobbysmith007 to jun66j5

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).

  • tracwysiwyg/htdocs/wysiwyg.js

    32473247        };
    32483248        TracWysiwyg.prototype.getNativeSelectionRange = function() {
    32493249            var selection = this.contentWindow.getSelection();
    3250             return selection.rangeCount > 0 ? selection.getRangeAt(0) : null;
     3250            return selection && selection.rangeCount > 0 ? selection.getRangeAt(0) : null;
    32513251        };
    32523252        TracWysiwyg.prototype.expandSelectionToElement = function(arg) {
    32533253            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

comment:8 Changed 6 years ago 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.

comment:9 Changed 6 years ago 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.

comment:10 Changed 5 years ago 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.

<      $('#properties table').cleanupTable();
>      if ($('#properties table').find('iframe.wysiwyg').length == 0) $('#properties table').cleanupTable();

comment:11 Changed 2 years ago by jun66j5

  • Resolution set to wontfix
  • Status changed from new to closed

I have no plan to modify tracwysiwygplugin for the issue.

Add Comment

Modify Ticket

as closed The owner will remain jun66j5.
The resolution will be deleted. Next status will be 'reopened'.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.