Intent to implement and ship: Unprefix -moz-user-select, unship mozilla-specific values.

[Emilio Cobos Álvarez]

Summary: Unprefix the -moz-user-select property, so that it works
without the -moz- prefix.

We happen to be supporting the -webkit- prefixed version of the
property, but other browsers support it also unprefixed, which causes a
lot of confusion.

As part of this work I'm also unshipping the following values from
content (or entirely, if they have no internal usage):

* -moz-all: Was meant to behave as an alias of `all`, but in practice
that's not true. Plus all external usage I found was followed by a
-webkit-user-select: all which would override it.

* -moz-text: It's an internal value which was introduced in bug
1181130. It's only used from contenteditable.css and I haven't
investigated removing it completely, but I'm restricting it to
user-agent stylesheets. I found no relevant external usage.

* tri-state, element, elements, toggle: We parse these but do nothing
with them (lol, I know, right?). They're no longer in the spec so should
be removed.

We also have a non-standard '-moz-none' alias to 'none' which I haven't
investigated removing yet, but probably should in a followup to this bug.

Bug: 1492958 for the removal of non-standard values, 1492739 for the
unprefixing.

Link to standard: https://drafts.csswg.org/css-ui-4/#propdef-user-select

Platform coverage: All

Estimated or target release: FF65

Preference behind which this will be implemented: None

Is this feature enabled by default in sandboxed iframes? Yes

DevTools bug: N/A

Do other browser engines implement this?

This is an interesting question. The current status is:

* Blink supports user-select unprefixed and -webkit- prefixed, with
the same values we'd support after this bug (except our non-standard
-moz-none alias).

* Edge supports the -ms- prefixed version of the property, and the
-webkit- prefixed version. Edge is the only engine to support the
'contain' value.

* WebKit only supports the -webkit- prefixed version.

So all browsers support as of today the -webkit- prefixed version of the
property, which is a fun state of affairs, with a slightly different set
of values.

I think we should try to unprefix sooner than later so this doesn't end
up being something similar to '-webkit-apperance'. Given Chrome supports
the same thing as us unprefixed, I think it's reasonable to do this.

web-platform-tests: Test coverage for all the values is pre-existing.
There's unfortunately little coverage in WPT, but a lot in our selection
and contenteditable tests.

Is this feature restricted to secure contexts? No, as this is merely
unprefixing an existing property.

Thoughts?

-- Emilio

[f***@rivoal.net]

Post by Emilio Cobos Álvarez
Summary: Unprefix the -moz-user-select property, so that it works
without the -moz- prefix.
We happen to be supporting the -webkit- prefixed version of the
property, but other browsers support it also unprefixed, which causes a
lot of confusion.
As part of this work I'm also unshipping the following values from
* -moz-all: Was meant to behave as an alias of `all`, but in practice
that's not true. Plus all external usage I found was followed by a
-webkit-user-select: all which would override it.
* -moz-text: It's an internal value which was introduced in bug
1181130. It's only used from contenteditable.css and I haven't
investigated removing it completely, but I'm restricting it to
user-agent stylesheets. I found no relevant external usage.
* tri-state, element, elements, toggle: We parse these but do nothing
with them (lol, I know, right?). They're no longer in the spec so should
be removed.
We also have a non-standard '-moz-none' alias to 'none' which I haven't
investigated removing yet, but probably should in a followup to this bug.
Bug: 1492958 for the removal of non-standard values, 1492739 for the
unprefixing.
Link to standard: https://drafts.csswg.org/css-ui-4/#propdef-user-select
Platform coverage: All
Estimated or target release: FF65
Preference behind which this will be implemented: None
Is this feature enabled by default in sandboxed iframes? Yes
DevTools bug: N/A
Do other browser engines implement this?
* Blink supports user-select unprefixed and -webkit- prefixed, with
the same values we'd support after this bug (except our non-standard
-moz-none alias).
* Edge supports the -ms- prefixed version of the property, and the
-webkit- prefixed version. Edge is the only engine to support the
'contain' value.
* WebKit only supports the -webkit- prefixed version.
So all browsers support as of today the -webkit- prefixed version of the
property, which is a fun state of affairs, with a slightly different set
of values.
I think we should try to unprefix sooner than later so this doesn't end
up being something similar to '-webkit-apperance'. Given Chrome supports
the same thing as us unprefixed, I think it's reasonable to do this.
web-platform-tests: Test coverage for all the values is pre-existing.
There's unfortunately little coverage in WPT, but a lot in our selection
and contenteditable tests.
Is this feature restricted to secure contexts? No, as this is merely
unprefixing an existing property.
Thoughts?
-- Emilio

I support doing this. This has existed forever, and is used quite a bit, so keeping that prefixed isn't helping anyone.

I would like to note however that the basic way the property works (inherited vs not, initial value of auto, different between 'auto' and 'text') is different in the spec and in your implementation. The difference is intentional, and necessary to support the `contain` value and to have a model that explains what happens on editable elements.

As long as you don't support the contain value, the difference in behavior should be minimal and barely noticeable in most cases, so this may not be a blocker, but if you're working on this property anyway, it seems to me that this would be a good time to switch to the spec's behavior while you're at it.

—Florian

[Emilio Cobos Álvarez]

Post by f***@rivoal.net

Post by Emilio Cobos Álvarez
Summary: Unprefix the -moz-user-select property, so that it works
without the -moz- prefix.
We happen to be supporting the -webkit- prefixed version of the
property, but other browsers support it also unprefixed, which causes a
lot of confusion.
As part of this work I'm also unshipping the following values from
* -moz-all: Was meant to behave as an alias of `all`, but in practice
that's not true. Plus all external usage I found was followed by a
-webkit-user-select: all which would override it.
* -moz-text: It's an internal value which was introduced in bug
1181130. It's only used from contenteditable.css and I haven't
investigated removing it completely, but I'm restricting it to
user-agent stylesheets. I found no relevant external usage.
* tri-state, element, elements, toggle: We parse these but do nothing
with them (lol, I know, right?). They're no longer in the spec so should
be removed.
We also have a non-standard '-moz-none' alias to 'none' which I haven't
investigated removing yet, but probably should in a followup to this bug.
Bug: 1492958 for the removal of non-standard values, 1492739 for the
unprefixing.
Link to standard: https://drafts.csswg.org/css-ui-4/#propdef-user-select
Platform coverage: All
Estimated or target release: FF65
Preference behind which this will be implemented: None
Is this feature enabled by default in sandboxed iframes? Yes
DevTools bug: N/A
Do other browser engines implement this?
* Blink supports user-select unprefixed and -webkit- prefixed, with
the same values we'd support after this bug (except our non-standard
-moz-none alias).
* Edge supports the -ms- prefixed version of the property, and the
-webkit- prefixed version. Edge is the only engine to support the
'contain' value.
* WebKit only supports the -webkit- prefixed version.
So all browsers support as of today the -webkit- prefixed version of the
property, which is a fun state of affairs, with a slightly different set
of values.
I think we should try to unprefix sooner than later so this doesn't end
up being something similar to '-webkit-apperance'. Given Chrome supports
the same thing as us unprefixed, I think it's reasonable to do this.
web-platform-tests: Test coverage for all the values is pre-existing.
There's unfortunately little coverage in WPT, but a lot in our selection
and contenteditable tests.
Is this feature restricted to secure contexts? No, as this is merely
unprefixing an existing property.
Thoughts?
-- Emilio

I support doing this. This has existed forever, and is used quite a bit, so keeping that prefixed isn't helping anyone.
I would like to note however that the basic way the property works (inherited vs not, initial value of auto, different between 'auto' and 'text') is different in the spec and in your implementation. The difference is intentional, and necessary to support the `contain` value and to have a model that explains what happens on editable elements.
As long as you don't support the contain value, the difference in behavior should be minimal and barely noticeable in most cases, so this may not be a blocker, but if you're working on this property anyway, it seems to me that this would be a good time to switch to the spec's behavior while you're at it.

Hmm, you're totally right, that's a very good point and I think we
should not unprefix it without fixing that.

I'll land the patches removing the obsolete values, and file a bug to
make that change before unprefixing.

Thanks Florian!

-- Emilio

Post by f***@rivoal.net
—Florian
_______________________________________________
dev-platform mailing list
https://lists.mozilla.org/listinfo/dev-platform

[James Graham]

Post by Emilio Cobos Álvarez
web-platform-tests: Test coverage for all the values is pre-existing.
There's unfortunately little coverage in WPT, but a lot in our selection
and contenteditable tests.

Can we upstream some of these tests to wpt? I don't know if there
are/were technical barriers that would prevent us doing that, but if
user gestures are required, the new testdriver APIs might fill the gap,
and if there is some other piece of missing functionality I would be
interested to know what that is.

[Emilio Cobos Álvarez]

Sorry for the lag replying to this.

Post by James Graham

Post by Emilio Cobos Álvarez
web-platform-tests: Test coverage for all the values is pre-existing.
There's unfortunately little coverage in WPT, but a lot in our
selection and contenteditable tests.

Can we upstream some of these tests to wpt? I don't know if there
are/were technical barriers that would prevent us doing that, but if
user gestures are required, the new testdriver APIs might fill the gap,
and if there is some other piece of missing functionality I would be
interested to know what that is.

Part of the difficulty is that we want these tests to show the caret,
which is something normal reftests don't. Right now all these reftests
are here:


https://searchfox.org/mozilla-central/source/layout/base/tests/test_reftests_with_caret.html

I'm not quite sure why they couldn't be normal reftests with the
ui.caretBlinkTime pref set to -1. Maybe David, Ehsan or Mats know.

But even with that, a lot of those require faking user input (like
arrows and such), whose effect depends on platform conventions. We're
using EventUtils for that right now, and skipping some tests in some
platforms.

I know the events thing is technically possible in WPT, is there any
example I could cargo-cult from?

I think in theory writing new caret tests with testharness.js and the
event stuff would be useful, and it may be possible to submit some of
the ones that don't depend on platform conventions.

-- Emilio

[Ehsan Akhgari]

Post by Emilio Cobos Álvarez
Sorry for the lag replying to this.

Post by James Graham

Post by Emilio Cobos Álvarez
web-platform-tests: Test coverage for all the values is pre-existing.
There's unfortunately little coverage in WPT, but a lot in our
selection and contenteditable tests.

Can we upstream some of these tests to wpt? I don't know if there
are/were technical barriers that would prevent us doing that, but if
user gestures are required, the new testdriver APIs might fill the gap,
and if there is some other piece of missing functionality I would be
interested to know what that is.

Part of the difficulty is that we want these tests to show the caret,
which is something normal reftests don't. Right now all these reftests
https://searchfox.org/mozilla-central/source/layout/base/tests/test_reftests_with_caret.html
I'm not quite sure why they couldn't be normal reftests with the
ui.caretBlinkTime pref set to -1. Maybe David, Ehsan or Mats know.

The reason for that is that these tests typically require input of some
sort (mouse, keyboard, for example), and as far as I know at least the
reftest framework didn't support synthesizing events, at least at the
time. So we ended up creating this small mini-reftest framework in
mochitest so that we can use the EventUtils facilities. (Also as far as I
remember setting prefs per reftest wasn't possible at the time either.)

Cheers,