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)
Core
DOM: Editor
Tracking
()
NEW
People
(Reporter: ayg, Unassigned)
Details
(Keywords: testcase)
Attachments
(1 file)
842 bytes,
text/html
|
Details |
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
Updated•14 years ago
|
Assignee: nobody → ehsan
Whiteboard: [post-2.0]
Updated•13 years ago
|
Assignee: ehsan → kaze
Comment 1•13 years ago
|
||
FTR, document.queryCommandEnabled("removeformat") now returns `false' for this case in Nightly.
Comment 2•13 years ago
|
||
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? :-)
Comment 3•13 years ago
|
||
Comment 4•13 years ago
|
||
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?
Comment 5•13 years ago
|
||
Aryeh: ping?
Reporter | ||
Comment 6•13 years ago
|
||
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.
Updated•12 years ago
|
Assignee: kaze → nobody
Comment 7•4 years ago
|
||
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.
Description
•