select tags in contentEditable can't be selected for removal
Categories
(Core :: Layout, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox67 | --- | fixed |
People
(Reporter: joerg, Assigned: emilio)
References
Details
Attachments
(3 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0
Steps to reproduce:
Open the attached test case. Select the <select> individually or with the surrounding letters (but without using select-all). Try to delete the selection.
Now use select-all and try to delete again.
Actual results:
In both cases the <select> should be removed from the editor block.
Expected results:
If the mouse selection contains the <select> and wasn't done using C-A, it can't be removed. With C-A, it can be removed.
|
Reporter | |
Comment 1•5 years ago
|
||
This is a regression from Firefox 64.
|
|
Reporter | |
Comment 2•5 years ago
|
||
https://hg.mozilla.org/integration/autoland/rev/8e88421b280c is the source of the regression according to mozregression.
|
Assignee | |
Comment 3•5 years ago
|
||
Thanks for the report, will take a look :)
|
|
Assignee | |
Comment 4•5 years ago
|
||
So, https://treeherder.mozilla.org/#/jobs?repo=try&revision=b9277e5c5914e669f8eec79ac4f5e2d693df84de is a patch that I think improves the behavior of contenteditable="true" -> contenteditable="false" considerably.
Need to check what our test suite thinks of that, write some tests, and send it for review if all the above goes well.
A possible workaround you could apply to that test-case for now could be something like:
<style>
span[contenteditable="false"], span[contenteditable="false"] select {
-moz-user-select: all;
}
</style>
For example. The mere reason this ever worked, looking at our code, seems to be luck.
|
|
Assignee | |
Comment 5•5 years ago
|
||
That looks pretty close! Let me write some tests.
|
|
Assignee | |
Comment 6•5 years ago
|
||
This makes our behavior a bit closer to Blink / WebKit.
This patch fixes multiple issues:
First, fixes the caret movement getting stuck on a <select> element inside an
editor. This is because of the IsRootOfAnonymousSubtree() check that I'm
removing. Instead of that, consider NAC unselectable in UsedUserSelect, just
like generated content. This makes us jump across it correctly, and doesn't
regress the test-case that was added in bug 989012.
Second, it allows to select nodes with user-select: none as long as you're on an
editor. This matches WebKit and Blink. It's something you could do earlier
regardless with user-select: all on the parent, which is why the reporter's
test-case worked before my patch. I think being able to jump across these and
delete them on an editor is the right thing to do.
It adds tests for all this plus the same thing working for non-editable contents
(there was no pre-existing test for that).
|
|
Assignee | |
Updated•5 years ago
|
|
||
Comment 7•5 years ago
|
||
|
|
||
Comment 8•5 years ago
|
||
Sigh, it looks like Phabricator discarded my review comment...
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4d5cbdd05859 Should be able to delete non-selectable and non-editable content in a contenteditable subtree. r=mats
|
||
Comment 10•5 years ago
|
||
Backed out for clipboard failures on test_browserElement_oop_CopyPaste.html
Backout link: https://hg.mozilla.org/integration/autoland/rev/34d90155fe7aa7e0170389dfceacec39d01e509a
Push link: https://hg.mozilla.org/integration/autoland/rev/4d5cbdd058591f298ca12a881cd3259dbdacc6d0
Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=225789029&repo=autoland&lineNumber=10823
|
||
Comment 11•5 years ago
|
||
Pushed by emilio@crisal.io: https://hg.mozilla.org/integration/autoland/rev/53951b4b6ac2 Should be able to delete non-selectable and non-editable content in a contenteditable subtree. r=mats
|
|
Assignee | |
Comment 12•5 years ago
|
||
Thanks, I removed the UsedUserSelect change, since it causes trouble for the anonymous <input> in <input type="number">.
|
||
Comment 13•5 years ago
|
||
| bugherder | ||
Description
•