547848 - queryCommandValue('backColor') always returns #FFFFFF

Status: NEW

(Core :: DOM: Editor, defect)

Description

[Marcos Almeida]

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

[Boris Zbarsky [:bzbarsky]]

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?

Comment 2

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(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

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

The solution here is probably not to change the current behavior but to have
another command querying "highlightColor"...

Comment 4

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

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

Comment 5

[alexander]

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?

Comment 6

[alexander]

:tumbleweed rolls: