Open
Bug 1061866
Opened 11 years ago
Updated 4 years ago
[contenteditable] data tags are stripped when pasting into a contenteditable element
Categories
(Core :: DOM: Editor, defect, P5)
Tracking
()
UNCONFIRMED
People
(Reporter: bendemboski, Unassigned)
Details
(Keywords: testcase)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.94 Safari/537.36
Steps to reproduce:
1. Go to http://jsfiddle.net/df6p6w2L/5/
2. Highlight the contents of the contenteditable div and press ctrl-x/cmd-x to cut it
3. Press ctrl-v/cmd-v to paste back into the contenteditable div
This also repros when copying, or when only cutting/copying a sub-range of the content (as long as it includes the <data> element).
Actual results:
As you can see in the "Editor contents" section, the newly-pasted content will be "Some text here" -- the <data> element has been removed and replaced with its contained content ("text").
Expected results:
The newly-pasted content should be "Some <data value="somevalue">text</data> here" i.e. should be identical to what was in the contenteditable div when it was cut.
Chromium does not exhibit this behavior -- it preserves the <data> element. Also, it appears to be an issue on the paste end, not on the cut end, because cutting content out of Chromium and pasting into Firefox exhibits this bug, and cutting content from Firefox and pasting into Chromium does not exhibit this bug.
Reporter | ||
Updated•11 years ago
|
Version: 31 Branch → 32 Branch
Updated•11 years ago
|
Component: Untriaged → Editor
Keywords: testcase
OS: Mac OS X → All
Product: Firefox → Core
Hardware: x86 → All
Comment 1•4 years ago
|
||
Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.
If you have reason to believe this is wrong, please write a comment and ni :jstutte.
Severity: normal → S4
Priority: -- → P5
You need to log in
before you can comment on or make changes to this bug.
Description
•