Open
Bug 547848
Opened 15 years ago
Updated 2 years ago
queryCommandValue('backColor') always returns #FFFFFF
Categories
(Core :: DOM: Editor, defect)
Tracking
()
NEW
People
(Reporter: marcosalmeida, Unassigned)
References
(Blocks 1 open bug, )
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100222 Minefield/3.7a2pre (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100222 Minefield/3.7a2pre (.NET CLR 3.5.30729)
Getting the background color via queryCommandValue('backColor') never works. It always returns #FFFFFF no matter what. 'foreColor' works fine.
Reproducible: Always
Steps to Reproduce:
1. Go to http://www.plexode.com/cgi-bin/eval2.py#var%20ifr%20%3D%20document.createElement(%27iframe%27)%3B%0Adocument.body.appendChild(ifr)%3B%0A%0AsetTimeout(function()%20{%0Avar%20doc%20%3D%20ifr.contentWindow.document%3B%0Adoc.designMode%20%3D%20%27on%27%3B%0Adoc.body.innerHTML%20%3D%20%27%3Cspan%20style%3D%22color%3Ablue%3Bbackground-color%3Ared%22%3Efoo%3C%2Fspan%3E%27%3B%0Avar%20span%20%3D%20doc.body.firstChild%3B%0Avar%20sel%20%3D%20ifr.contentWindow.getSelection()%3B%0Avar%20rng%20%3D%20doc.createRange()%3B%0Arng.setStart(span.firstChild%2C%201)%3B%0Arng.setEnd(span.firstChild%2C%202)%3B%0Asel.removeAllRanges()%3B%0Asel.addRange(rng)%3B%0Aalert(%27foreColor%20%3D%20%27%2Bdoc.queryCommandValue(%27foreColor%27)%2B%27%20%3B%20backColor%20%3D%20%27%2Bdoc.queryCommandValue(%27backColor%27))%3B%0A}%2C%200)%3B%0A
2. Click "eval once"
--> The alert shows the results of qCV(foreColor) and qCV(backColor). The first one is correct, the second one wrong.
You can also see this in a contentEditable div instead of a designMode iframe at:
http://www.plexode.com/cgi-bin/eval3.py#ht=%3Cdiv%20contentEditable%3E%3Cspan%20id%3D'myspan'%20style%3D%22color%3Ablue%3Bbackground-color%3Ared%22%3Efoo%3C%2Fspan%3E%3C%2Fdiv%3E&ohh=1&ohj=1&jt=var%20span%20%3D%20document.getElementById('myspan')%3B%0Avar%20sel%20%3D%20window.getSelection()%3B%0Avar%20rng%20%3D%20document.createRange()%3B%0Arng.setStart(span.firstChild%2C%201)%3B%0Arng.setEnd(span.firstChild%2C%202)%3B%0Asel.removeAllRanges()%3B%0Asel.addRange(rng)%3B%0Aalert('foreColor%20%3D%20'%2Bdocument.queryCommandValue('foreColor')%2B'%20%3B%20backColor%20%3D%20'%2Bdocument.queryCommandValue('backColor'))%3B%0A&ojh=0&ojj=0&ms=100&oth=0&otj=0&cex=0
Actual Results:
queryCommandValue('backColor') always returns #FFFFFF
Expected Results:
queryCommandValue('backColor') should return the background color at the current selection position, e.g. rgb(255, 0, 0)
This affects Google properties.
Comment 1•15 years ago
|
||
It looks based on the code like queryCommandValue('backColor') will return the background color of the nearest _block_ containing the selection. And that happens because nsHTMLEditor::GetBackgroundColorState passes PR_TRUE for the last argument of GetCSSBackgroundColorState. And nsBackgroundColorStateCommand::GetCurrentState calls GetBackgroundColorState.
That code dates back to 2002; I have no idea why it's written the way it is. Daniel, do you see any reason to not pass PR_FALSE in GetBackgroundColorState?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•15 years ago
|
||
(In reply to comment #1)
> It looks based on the code like queryCommandValue('backColor') will return the
> background color of the nearest _block_ containing the selection. And that
> happens because nsHTMLEditor::GetBackgroundColorState passes PR_TRUE for the
> last argument of GetCSSBackgroundColorState. And
> nsBackgroundColorStateCommand::GetCurrentState calls GetBackgroundColorState.
>
> That code dates back to 2002; I have no idea why it's written the way it is.
> Daniel, do you see any reason to not pass PR_FALSE in GetBackgroundColorState?
I was not involved in Midas but I suspect it was done on purpose. Content
editors tend to offer first UI for block-bg-color and only if possible UI for inline-bg-color. (some tools call them Background Color and Highlight Color).
Since at the time of creation of Midas, Composer was not able to handle the
latter, it's probably PR_FALSE to handle only the former...
Sorry that's the only explanation I have, but it's plausible.
Comment 3•15 years ago
|
||
The solution here is probably not to change the current behavior but to have
another command querying "highlightColor"...
Comment 4•13 years ago
|
||
Correct behavior here for both backColor and hiliteColor is to return the value for the nearest ancestor that has a non-transparent background-color:
http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#effective-command-value
Blocks: richtext2
It's been 9 years and the only thing that has changed is that it now returns transparent rather than white. document.queryCommandValue('hiliteColor') also doesn't work. Do you guys plan to do something about it or nobody cares?
Updated•3 years ago
|
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•