#9532 closed defect (fixed)
Editor: Safari doesn't always enable background color (TextColor Plugin)
Reported by: | Jared Jurkiewicz | Owned by: | Jared Jurkiewicz |
---|---|---|---|
Priority: | high | Milestone: | 1.3.2 |
Component: | General | Version: | 1.3.0 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
Editor: Safari doesn't always enable background color (TextColor? Plugin)
This was reported by a co-worker of mine and I verified it occurs:
Go to either of these pages:
http://download.dojotoolkit.org/release-1.2.3/dojo-release-1.2.3/dijit/tests/test_Editor.html
http://download.dojotoolkit.org/release-1.3.1/dojo-release-1.3.1/dijit/tests/test_Editor.html
I scrolled down to the editor that has a background color plugin. I highlighted random parts of the text. Sometimes the background color button becomes enabled, sometimes it doesn't (it's supposed to always be enabled if text is highlighted). I can highlight the same text twice and one time it will enable the button and one time it won't. However, it seems that most of the time, selecting text which is all on one line will enable the button, and most of the time selecting multiple lines will not enable the button.
I also determined what causes this from investigation and talking to Liu Cougar. The problem stems from onDisplayChanged not getting called when it should be. Normally onDisplayChanged gets called when a caret shifts or other events occur in the document. In this case, the mouse is beingused to select, and of course the display is getting changed to indicate that ... but WebKit? itself isn't firing the event, so onDisplayChanged isn't getting fired. There is thankfully a very simple fix for this (And Liu Cougar was fine with it).
In dijit/_editor/RichText.js:
Function: onLoad:
Add the following line right after the spot we do a correction for IE:
if(dojo.WebKit?){
this.connect(this.document, "onmouseup", "onDisplayChanged");
}
Liu was okay with me making this tweak, so assigning it to me.
Attachments (1)
Change History (9)
comment:1 Changed 12 years ago by
Changed 12 years ago by
Attachment: | WebKit_listener.patch added |
---|
comment:2 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:3 Changed 12 years ago by
Milestone: | tbd |
---|
comment:5 Changed 12 years ago by
Milestone: | → 1.3.2 |
---|
Note that I saw trhis specifically in Safari 3.2.3 and such, and my co-worker hit it on Safari 3.0.2.
In any event, it's a simple workaround. Patch coming!