#10096 closed defect (fixed)
queryCommandValue + hiliteColor
Reported by: | emorvill | Owned by: | Jared Jurkiewicz |
---|---|---|---|
Priority: | high | Milestone: | 1.4 |
Component: | Editor | Version: | 1.3.2 |
Keywords: | hilitecolor | Cc: | bill, liucougar |
Blocked By: | Blocking: |
Description
A queryCommandValue with a hiliteColor doesn't work.
In dijit._editor.plugins.TextColor?, if you overwrite the method updateState like this :
updateState: function(){ var _e = this.editor; var _c = this.command; if(!_e || !_e.isLoaded || !_c.length){ return; } if(this.button){ var value; try{ value = _e.queryCommandValue(_c); }catch(e){ console.error(e); } console.warn("Update State ::: ", _c, " : ", value); } }
value is always equals to "transparent".
Attachments (4)
Change History (17)
comment:1 Changed 11 years ago by
Component: | Dijit → Editor |
---|---|
Milestone: | 1.3.3 → tbd |
Owner: | set to Jared Jurkiewicz |
comment:2 Changed 11 years ago by
comment:3 Changed 11 years ago by
I'm unclear what the actual bug (or ramifications of the bug) are. That the hilite-color and background-color buttons don't reflect the current state of the text where the caret is?
See also #5829.
comment:4 Changed 11 years ago by
Hi,
I made a test : http://volantis.ccett.fr/test_hilitecolor/dijit/tests/test_Editor.html
Firefox 3.x :
- The hiliteColor always returns the value transparent
- The foreColor works and returns an hexadecimal value.
IE 6/7/8 :
- The hiliteColor works and returns an Integer value.
- The foreColor works and returns an Integer value.
Safari 4 /Chrome :
- The hiliteColor works and returns a rgb/rgba value (rgb(135,41,41) for example)
- The foreColor works and returns a rgb/rgba value (rgb(135,41,41) for example)
I think that the bug is on Firefox for hiliteColor command. (It seems impossible to get the right value). May be it will be easier to always returns an hexadecimal value in all browsers ?
comment:5 Changed 11 years ago by
if http://volantis.ccett.fr doesn't work you can test on http://volantis.rec.orange.fr/test_hilitecolor/dijit/tests/test_Editor.html
comment:6 Changed 11 years ago by
The problem is when useCSS is set to false after the execCommand. With the patch, I get the right value on Firefox.
comment:7 Changed 11 years ago by
I'm not sure that patch is appropriate, as it is going to change a lot of default behavior. In other words, the styling of all elements is going to change. That may have far-reaching effects to other actions.
comment:8 Changed 11 years ago by
I'm assuming that updateState method is yours, if so, then why not just implement it like:
updateState: function(){ var _e = this.editor; var _c = this.command; if(!_e || !_e.isLoaded || !_c.length){ return; } if(this.button){ var value; try{ if(dojo.isMoz){ e.execCommand("styleWithCSS", false, true); value = _e.queryCommandValue(_c); e.execCommand("styleWithCSS", false, false); }else{ value = _e.queryCommandValue(_c); } }catch(e){ console.error(e); } console.warn("Update State ::: ", _c, " : ", value); } }
That avoids having to change the default editor behavior (been around for years), for something you desire to over-ride.
Changed 11 years ago by
Attachment: | test_Editor.2.html added |
---|
Updated over-ride that works with current editor.
comment:9 Changed 11 years ago by
Hi,
It works with this code :
updateState: function(){ var _e = this.editor; var _c = this.command; if(!_e || !_e.isLoaded || !_c.length){ return; } if(this.button){ var value; try{ if(dojo.isMoz){ _e.document.execCommand("styleWithCSS", false, true); value = _e.queryCommandValue(_c); _e.document.execCommand("styleWithCSS", false, false); }else{ value = _e.queryCommandValue(_c); } }catch(e){ console.error(e); } console.warn("Update State ::: ", _c, " : ", value); } }
I think that the queryCommandValue has to work fine without specific code. Maybe, the problem could be resolved in a future version ? I let you decide ;) Thanks for your support
comment:10 Changed 11 years ago by
Cc: | bill wildbill liucougar added |
---|
I added a testcase that alters your over-ride and gets it to work without making any changes to RichText?.js. I'm loathe to change the editor from named tags to CSS styling in 1.X, as it has been the normal editor behavior for years.
Bill, Liu,
Any opinions here? I can change editor over to do styleWithCSS true, but it alters a long-standing behavior. I'm worried what impact such a change might have.
Changed 11 years ago by
Attachment: | possible.patch added |
---|
Another possible patch that solves it without altering the default value the editor is using for styleWithCSS
comment:11 Changed 11 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:12 Changed 11 years ago by
Cc: | wildbill removed |
---|---|
Milestone: | tbd → 1.4 |
Yah, I don't see any reason to change the editor's behavior in general. I'm sure it's a religious issue that some people feel <b> and <strong> are evil but I don't really care.
I would like to have editor output be consistent across browsers but we can do that with pre/post filters (both DOM based and regex based) so I don't see a pressing need to alter the representation of styles while the document is being edited.
does this happen for all browsers and all test cases?