queryCommandValue('backColor') always returns #FFFFFF

NEW
Unassigned

Status

()

9 years ago
3 years ago

People

(Reporter: marcosalmeida, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

9 years ago
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.
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
(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.
The solution here is probably not to change the current behavior but to have
another command querying "highlightColor"...
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: 685931
You need to log in before you can comment on or make changes to this bug.