RESOLVED FIXED 51164
execCommand('styleWithCSS') is ignored when selection isn't inside a contenteditable area
https://bugs.webkit.org/show_bug.cgi?id=51164
Summary execCommand('styleWithCSS') is ignored when selection isn't inside a contente...
Ryosuke Niwa
Reported 2010-12-15 22:36:55 PST
WebKit ignores document.execCommand('styleWithCSS', false, true/false) when the document's selection isn't inside a contenteditable area. Since styleWithCSS doesn't modify DOM, WebKit should respect calls even when the selection isn't in an editable region.
Attachments
demo (698 bytes, text/html)
2010-12-15 22:42 PST, Ryosuke Niwa
no flags
fixes the bug (4.89 KB, patch)
2010-12-16 11:24 PST, Ryosuke Niwa
no flags
Ryosuke Niwa
Comment 1 2010-12-15 22:42:42 PST
Darin Adler
Comment 2 2010-12-16 08:24:16 PST
(In reply to comment #0) > styleWithCSS doesn't modify DOM I didn’t know that! I thought that it added style attributes to DOM elements.
Ryosuke Niwa
Comment 3 2010-12-16 10:01:26 PST
(In reply to comment #2) > (In reply to comment #0) > > styleWithCSS doesn't modify DOM > > I didn’t know that! I thought that it added style attributes to DOM elements. Subsequent execCommands DO modify DOM by inserting spans and adding style attributes but styleWithCSS itself doesn't. It's simply a flag in Editor class: http://trac.webkit.org/browser/trunk/WebCore/editing/EditorCommand.cpp?rev=73886#L982 http://trac.webkit.org/browser/trunk/WebCore/editing/Editor.h?rev=73886#L168 And it's not unusual for someone to call StyleWithCSS without putting caret inside an editable region. For example, text editor can call it right up front to enforce the use of CSS. We just had that bug in browser scope test (it was calling styleWithCSS before setting up selection). And apparently, we're the only browser that requires caret/selection being inside an editable region for StyleWithCSS.
Darin Adler
Comment 4 2010-12-16 10:14:04 PST
I see. This command simply sets a flag. This should be very easy to fix!
Julie Parent
Comment 5 2010-12-16 10:45:30 PST
There is a little bit of subtlety here ... what happens if a document has 5 separate editable roots, the selection is in none of them, and you call execCommand('styleWithCSS')? Does it effect all of them?
Julie Parent
Comment 6 2010-12-16 10:47:32 PST
Anyway, making this always enabled looks as easy as changing enabledInRichlyEditableText to enabled in { "StyleWithCSS", { executeStyleWithCSS, supported, enabledInRichlyEditableText, stateStyleWithCSS, valueNull, notTextInsertion, doNotAllowExecutionWhenDisabled } }, in WebCore/editing/EditorCommand.cpp
Darin Adler
Comment 7 2010-12-16 10:47:45 PST
(In reply to comment #5) > There is a little bit of subtlety here ... what happens if a document has 5 separate editable roots, the selection is in none of them, and you call execCommand('styleWithCSS')? Does it effect all of them? We don’t have any per-editable-root settings. I presume this sets a per-document flag in WebKit now and should continue to do so. I’d imagine this is how ti works in other browsers as well.
Ryosuke Niwa
Comment 8 2010-12-16 11:02:12 PST
(In reply to comment #6) > Anyway, making this always enabled looks as easy as changing enabledInRichlyEditableText to enabled in > > { "StyleWithCSS", { executeStyleWithCSS, supported, enabledInRichlyEditableText, stateStyleWithCSS, valueNull, notTextInsertion, doNotAllowExecutionWhenDisabled } }, Indeed. I'm going to post a patch in a minute. (In reply to comment #7) > (In reply to comment #5) > > There is a little bit of subtlety here ... what happens if a document has 5 separate editable roots, the selection is in none of them, and you call execCommand('styleWithCSS')? Does it effect all of them? > > We don’t have any per-editable-root settings. I presume this sets a per-document flag in WebKit now and should continue to do so. I’d imagine this is how ti works in other browsers as well. What Darin said. I think a lot of developers don't realize this because most of editing apps use an iframe + design mode to work-around Firefox's quirk to modify the editing host.
Ryosuke Niwa
Comment 9 2010-12-16 11:24:05 PST
Created attachment 76792 [details] fixes the bug
Ryosuke Niwa
Comment 10 2010-12-16 11:59:11 PST
Thanks for the review, Darin. Landing now.
Ryosuke Niwa
Comment 11 2010-12-16 12:02:09 PST
Comment on attachment 76792 [details] fixes the bug Clearing flags on attachment: 76792 Committed r74204: <http://trac.webkit.org/changeset/74204>
Ryosuke Niwa
Comment 12 2010-12-16 12:02:14 PST
All reviewed patches have been landed. Closing bug.
WebKit Review Bot
Comment 13 2010-12-16 15:39:52 PST
http://trac.webkit.org/changeset/74204 might have broken Leopard Intel Debug (Tests)
Note You need to log in before you can comment on or make changes to this bug.