Failing WPT css/css-ui/user-select-none-in-editable.html
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
People
(Reporter: twisniewski, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug, )
Details
https://wpt.fyi/results/css/css-ui/user-select-none-in-editable.html
Safari and Chrome pass.
Comment 1•1 year ago
|
||
[Mass-triaging the batch of recently filed "Failing WPT" bugs as S3. If you want to filter out this bugmail, you can search for the string "volatile knot".]
Comment 2•1 year ago
•
|
||
Live link to test: http://wpt.live/css/css-ui/user-select-none-in-editable.html
It looks like the issue here is that we're honoring user-select:none in the editable element, when we should not, per this spec text (which depends on support for the contain value for this property):
The used value is the same as the computed value, except:
on editable elements where the used value is alwayscontainregardless of the computed value
Comment 3•9 months ago
•
|
||
Hmm, it looks like we've already got a special-case that purports to implement the spec text that I quoted in comment 2:
static StyleUserSelect UsedUserSelect(const nsIFrame* aFrame) {
...
// Per https://drafts.csswg.org/css-ui-4/#content-selection:
//
// The used value is the same as the computed value, except:
//
// 1 - on editable elements where the used value is always 'contain'
// regardless of the computed value
...
if (aFrame->IsTextInputFrame() || IsEditingHost(aFrame)) {
// We don't implement 'contain' itself, but we make 'text' behave as
// 'contain' for contenteditable and <input> / <textarea> elements anyway so
// this is ok.
return StyleUserSelect::Text;
Anyway, this is a breadcrumb to take a look at here... either we're not triggering this^ return statement for some reason, or the alluded-to we make 'text' behave as 'contain' code isn't working properly.
Description
•