select tags in contentEditable can't be selected for removal

RESOLVED FIXED in Firefox 67

Status

()

defect
RESOLVED FIXED
6 months ago
5 months ago

People

(Reporter: joerg, Assigned: emilio)

Tracking

65 Branch
mozilla67
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox67 fixed)

Details

Attachments

(3 attachments)

Posted file select.html

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.

This is a regression from Firefox 64.

https://hg.mozilla.org/integration/autoland/rev/8e88421b280c is the source of the regression according to mozregression.

Thanks for the report, will take a look :)

Blocks: 1506547
Status: UNCONFIRMED → NEW
Component: Untriaged → Layout
Ever confirmed: true
Flags: needinfo?(emilio)
Product: Firefox → Core

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.

That looks pretty close! Let me write some tests.

Assignee: nobody → emilio

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).

Flags: needinfo?(emilio)
Posted file Testcase #2

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
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

Thanks, I removed the UsedUserSelect change, since it causes trouble for the anonymous <input> in <input type="number">.

Flags: needinfo?(emilio)
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
You need to log in before you can comment on or make changes to this bug.