[Webkit-unassigned] [Bug 17594] queryCommandState returns false for Underline command when no selection is made

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Sep 16 17:48:09 PDT 2010


https://bugs.webkit.org/show_bug.cgi?id=17594


Ryosuke Niwa <rniwa at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rniwa at webkit.org




--- Comment #6 from Ryosuke Niwa <rniwa at webkit.org>  2010-09-16 17:48:10 PST ---
(In reply to comment #4)
> when there is no text selected and an execCommand for underline is performed, immediately after, executing queryCommandState('underline') returns false.

This is correct behavior because if you do execCommand('underline', false, null) inside a underlined content, then we remove the underline from the typing style.  If you typed text without moving caret or clicking anywhere, you should be able to text without underline.

>However the document is in the underline state because if you type you can see the results are underlined. You can observe the same behavior when doing an execCommand on strikethrough as well.

I don't think this is an accurate description.  Yes, you do get underlined text if you moved the caret or clicked some other place (even the same location) to type text.  But that's consistent with other browsers such as Firefox.

> This is inconsistent behavior and : 
> 1) it's inconsistent with the bold/italic commands because those work as expected under these conditions
> 2) when you have performed execCommand on underline/strikethrough and then furhter performing an execCommand on bold/italic, you cannot toggle back underline/strikethrough, without toggling back bold/italic first. So as you can note, it gets even more worse and I cannot think of a simple workaround to fix this problem on my end.

I think you're encountering the bug 44560, which has been fixed recently.

> 3)This works just fine on all other browsers that support contenteditable.

I don't really understand what kind of problems you're experiencing.  As far as I checked the test cases on this page, WebKit (TOT) is behaving exactly as I expect it to behave.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list