Open Bug 649138 Opened 14 years ago Updated 4 years ago

execCommand("removeformat") fails under strange circumstances (minimal test-case attached)

Categories

(Core :: DOM: Editor, defect, P5)

defect

Tracking

()

People

(Reporter: ayg, Unassigned)

Details

(Keywords: testcase)

Attachments

(1 file)

data:text/html,<!doctype html> <body contenteditable=true> <table></table> <script> var test = document.querySelector("table"); test.innerHTML = "<b>foo</b>"; getSelection().collapse(test, 0); getSelection().extend(test, 1); document.execCommand("removeformat", false, ""); </script> In Chrome 12 dev and Opera 11: "foo" is unbolded. In Firefox 4.0 (also tested in April 11 nightly): "foo" is bolded. Any of the following makes Firefox behave as expected: * Changing the <table> to a <p> * Doing getSelection().selectAllChildren(test) instead of collapse/extend * Stepping through the code in Firebug instead of running it directly
Assignee: nobody → ehsan
Whiteboard: [post-2.0]
Assignee: ehsan → kaze
FTR, document.queryCommandEnabled("removeformat") now returns `false' for this case in Nightly.
Yet another range promotion issue, this time in RemoveInlinePropertyImpl(). Both `selectAllChildren' and `collapse/extend' select the <table> element, but: • when using .selectAllChildren(test), PromoteInlineRange() extends the selection to <body>, and the <b> tag is successfully removed; • when using .collapse(test)/.extend(test), IsEditable() returns `false' for the <table> element, and the selection isn’t extended by PromoteInlineRange(). The problem is, with .extend() the selection anchor nodes behave as if they didn’t have any primary frame (node->GetPrimaryFrame() returns null), which is the reason why IsEditable() returns false. Looking as nsTypedSelection::SelectAllChildren() and Extend()… Volkmar, any idea? :-)
Attached file testcase
This seems fun actually... Aryeh, your test is actually not passing with Chrome 15. I didn't try other versions of Chrome though. But, to make things nice, the testcase Fabien attached is actually describing the behavior you mentioned: working on Chrome/Opera but not on Firefox. Do we still want the original test case to pass?
Keywords: testcase
OS: Linux → All
Hardware: x86 → All
Whiteboard: [post-2.0]
Aryeh: ping?
Sorry, didn't notice this. I can confirm Chrome 15 dev now also fails, as does Firefox 8.0a2. If you modify the testcase to use selectAllChildren() instead of collapse()/extend(), then Chrome still fails but Firefox passes. So Chrome seems to have a different bug that happens to randomly cause it to fail the same test-case for other reasons. Actually, Chrome's bug is reproducible in my conformance test suite, so I've added a test case (which Firefox passes): http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=d1ddd1a1 This bug still stands -- both Gecko and WebKit are now wrong on my original test case.
Assignee: kaze → nobody

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority and severity.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Severity: minor → S4
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: