Bug 16049 - execCommand('backColor') fails on collapsed selections
Summary: execCommand('backColor') fails on collapsed selections
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: All OS X 10.4
: P2 Normal
Assignee: Nobody
URL: http://nick-santos.com/tests/backgrou...
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-19 07:24 PST by Nick Santos
Modified: 2008-06-19 18:16 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Santos 2007-11-19 07:24:58 PST
Repro Steps:
1) Place the cursor in a contentEditable element.
2) Execute document.execCommand('backColor', false, '#f00') in JavaScript.
3) Type some text.

Expected Result:
The new text should have a red background.

Actual Result:
The new text keeps the same background.

Notes:
'backColor' works ok when text is actually selected.
If we replace 'backColor' with 'foreColor' in step #2, the new text is red as expected.
Verified on Safari3/Win and Webkit-Nightly/OSX.
Comment 1 Mark Rowe (bdash) 2007-11-19 08:11:45 PST
JSEditor.cpp shows that BackColor and ForeColor have different values for the enabledFn member of their CommandImp:

WebCore/editing/JSEditor.cpp:        { "BackColor", { execBackColor, enabledAnyRichlyEditableRangeSelection, stateNone, valueBackColor } },
WebCore/editing/JSEditor.cpp:        { "ForeColor", { execForeColor, enabledAnySelection, stateNone, valueForeColor } },


BackColor requires a range selection which would cause the command to be disabled for collapsed selections.  The fix here may be as simple as changing the enabledFn to enabledAnyRichlyEditableSelection.  A quick test suggests that this gives the same behaviour as IE on the test case.
Comment 2 Eric Seidel (no email) 2008-01-10 12:58:33 PST
So it sounds like all this bug needs is some understanding of what a change to enabledAnyRichlyEditableSelection would mean for the rest of the web. :)  I guess we solve that with a test case.
Comment 3 Julie Parent 2008-06-19 15:54:40 PDT
+1 on fixing this. We have horrible, horrible hacks in place to get this working in the Google editor.  I'd love to get rid of them!
Comment 4 Justin Garcia 2008-06-19 16:11:14 PDT
(In reply to comment #1)
> JSEditor.cpp shows that BackColor and ForeColor have different values for the
> enabledFn member of their CommandImp:
> 
> WebCore/editing/JSEditor.cpp:        { "BackColor", { execBackColor,
> enabledAnyRichlyEditableRangeSelection, stateNone, valueBackColor } },
> WebCore/editing/JSEditor.cpp:        { "ForeColor", { execForeColor,
> enabledAnySelection, stateNone, valueForeColor } },

Yikes that's completely wrong, BackColor should have enabledAnyRichlyEditableRangeSelection, and I don't know why ForeColor has enabledAnySelection, it should be disabled in a plain text region too.
Comment 5 Justin Garcia 2008-06-19 16:12:04 PDT
> BackColor should have enabledAnyRichlyEditableRangeSelection

that should read "enabledAnyRichlyEditableSelection".
Comment 6 Justin Garcia 2008-06-19 18:16:35 PDT
http://trac.webkit.org/changeset/34682