WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
fixes the bug
(4.89 KB, patch)
2010-12-16 11:24 PST
,
Ryosuke Niwa
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Ryosuke Niwa
Comment 1
2010-12-15 22:42:42 PST
Created
attachment 76735
[details]
demo
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.
Top of Page
Format For Printing
XML
Clone This Bug