Bug 242006

Created attachment 460492 [details] Test case

We could attempt to default to `UserSelectAllIsAlwaysNonEditable` in more places, but that still comes with compat risk for native apps that embed web views, as well as Safari-UA-specific content. This could be partially mitigated with a LoA check, but it still seems risky, due to how widely used this property is.

(In reply to Wenson Hsieh from comment #2) > We could attempt to default to `UserSelectAllIsAlwaysNonEditable` in more ..I meant to write `UserSelectAllDoesNotAffectEditability`, of course :)

So the current user-select: all behavior was specifically designed to be used in Mail and other applications which want to treat an attachment file as one non-editable thing that can be selected on its own. It seems like `user-select: all` needs a different behavior but I agree with you that making this change is quite risky in terms of backwards compatibility. We may need to add SDK check or preserve the old behavior just in `-webkit-user-select`.

(In reply to Ryosuke Niwa from comment #4) > So the current user-select: all behavior was specifically designed to be > used in Mail and other applications which want to treat an attachment file > as one non-editable thing that can be selected on its own. > > It seems like `user-select: all` needs a different behavior but I agree with > you that making this change is quite risky in terms of backwards > compatibility. We may need to add SDK check or preserve the old behavior > just in `-webkit-user-select`. I think we should just make the user-select behavior match other browsers, and have other applications use -webkit-user-modify to override editability. Other apps shouldn't hold back interopability on the web. Preserving the old behavior for just -webkit-user-select wouldn't really help in this case, since both unprefixed and prefixed versions are used here, so the unprefixed version would win (even if not the case, the prefixed version is set to `auto` and not `all`).

(In reply to Tim Nguyen (:ntim) from comment #5) > (In reply to Ryosuke Niwa from comment #4) > > So the current user-select: all behavior was specifically designed to be > > used in Mail and other applications which want to treat an attachment file > > as one non-editable thing that can be selected on its own. > > > > It seems like `user-select: all` needs a different behavior but I agree with > > you that making this change is quite risky in terms of backwards > > compatibility. We may need to add SDK check or preserve the old behavior > > just in `-webkit-user-select`. > > I think we should just make the user-select behavior match other browsers, > and have other applications use -webkit-user-modify to override editability. > Other apps shouldn't hold back interopability on the web. It's irresponsible to break iOS specific content or iOS applications like that. Think of end users who have been using an app suddenly faced with an erroneous behavior in new version of iOS. > Preserving the old behavior for just -webkit-user-select wouldn't really > help in this case, since both unprefixed and prefixed versions are used > here, so the unprefixed version would win (even if not the case, the > prefixed version is set to `auto` and not `all`). I don't follow. They specify user-select and -webkit-user-select. If -webkit-user-select preserved the old behavior, then it would work precisely because it also specify user-select, which overrides the behavior of the prefixed version.

(In reply to Ryosuke Niwa from comment #6) > I don't follow. They specify user-select and -webkit-user-select. If > -webkit-user-select preserved the old behavior, then it would work precisely > because it also specify user-select, which overrides the behavior of the > prefixed version. In the case of Outlook, `-webkit-user-select: auto; user-select: all;` were both set. The computed value for both `-webkit-user-select` and `user-select` would be `all` regardless since both were specified. Unless you're asking to make the computed value differ, and always prefer the `-webkit-` prefixed value, which would be very unusual to do.

Created attachment 460498 [details] test with different cases for cross testing browsers. I tested on Desktop only for now. Case 1: outlook breakage -webkit-user-select:auto;user-select: all; | Browser | Edit | Computed value | Version | --------------------------------------------------------------------------| | Safari | FAIL | user-select: all | 18614.1.14.1.15. | | Firefox | OK | user-select: all | 103.0a1 (2022-06-21) | | Chrome | OK | user-select: all | 104.0.5106.0 | user-select: all; | Browser | Edit | Computed value | Version | --------------------------------------------------------------------------| | Safari | FAIL | user-select: all | 18614.1.14.1.15. | | Firefox | OK | user-select: all | 103.0a1 (2022-06-21) | | Chrome | OK | user-select: all | 104.0.5106.0 | -webkit-user-select:auto; | Browser | Edit | Computed value | Version | --------------------------------------------------------------------------| | Safari | OK | user-select: text | 18614.1.14.1.15. | | Firefox | OK | user-select: auto | 103.0a1 (2022-06-21) | | Chrome | OK | -webkit-user-select:auto | 104.0.5106.0 | Fun… There is an issue for the compat spec so we can add it on the spec. https://github.com/whatwg/compat/issues/135 This should probably be clarified. The implementation should not regressed the Web indeed. Is there a way to have a quirks identifying internal apps. We want to find a good compromise to minimize breakage. In the case of Outlook are we sure (I haven't checked yet), that Microsoft is sending the same style to all browsers? Or do they send something specific to each browsers? Previous discussions about this. https://docs.google.com/document/d/1158E0YvlUJ5Lwd-8XZBFqE2Ow_FWLrNVik1MFqk3WRU/edit https://bugs.chromium.org/p/chromium/issues/detail?id=605419 https://bugzilla.mozilla.org/show_bug.cgi?id=1506547 (thinking mode) Unprefixing: https://bugs.webkit.org/show_bug.cgi?id=208677 Chromium unprefixed user-select in https://bugs.chromium.org/p/chromium/issues/detail?id=461018 Note that Firefox had to implement -webkit-user-select for compat reasons, but with specific behavior aligned with the behavior of what other browsers were doing in -webkit- only world. See the discussion specifically in https://bugzilla.mozilla.org/show_bug.cgi?id=1506547#c1 (still thinking)

Created attachment 460499 [details] actual markup from outlook So Outlook is sending the same markup to Firefox Android and Safari iOS, but with a very specific CSS rule: ``` <div id="editorDiv" aria-multiline="true" role="textbox" contenteditable="true" class="_2Ty8EjISo75bsCGOwzk795" spellcheck="false" aria-label="Message: " > <div> <span id="_rooster_watermarkSpan">Type '@' to mention someone</span> </div> </div> <style> ._2Ty8EjISo75bsCGOwzk795 { -webkit-user-select: auto; -ms-user-select: all; user-select: all; -moz-user-select: text; -webkit-user-modify: read-write; } </style> ```

(In reply to Tim Nguyen (:ntim) from comment #7) > (In reply to Ryosuke Niwa from comment #6) > > > I don't follow. They specify user-select and -webkit-user-select. If > > -webkit-user-select preserved the old behavior, then it would work precisely > > because it also specify user-select, which overrides the behavior of the > > prefixed version. > > In the case of Outlook, `-webkit-user-select: auto; user-select: all;` were > both set. The computed value for both `-webkit-user-select` and > `user-select` would be `all` regardless since both were specified. Right, and if we implemented the new behavior just for user-select: all and not -webkit-user-select: all, then outlook will still get the new behavior since it specifies both properties while other clients that might be relying on old behaviors of -webkit-user-select: all will continue to get the same behavior. It's still possible though that there are content out there targeting iOS or Safari specifically and specify both user-select and -webkit-user-select and expect the old WebKit behavior so if those contents exist, then we're really screwed here. At this point, I suggest we revert https://commits.webkit.org/249800@main for now and try again later.

There was (In reply to Ryosuke Niwa from comment #10) > It's still possible though that there are content out there targeting iOS or > Safari specifically and specify both user-select and -webkit-user-select and > expect the old WebKit behavior so if those contents exist, then we're really > screwed here. There was a resolution from the CSS WG about this. https://github.com/w3c/csswg-drafts/issues/4839 > RESOLVED: For aliased properties both sides of the alias get new values as defined as a general rule

Pull request: https://github.com/WebKit/WebKit/pull/2094

Keeping this bug since it has more information, but going to fix the original bug by reverting.

Bug 242366 reverts unprefixing

So it's pretty clear that the unprefixed version should behave like all other browsers and shouldn't make the element non-editable. On the other hand, maybe the behavior of webkit prefixed version need to stay the same (with edibility effect) for backwards compatibility.

This bug is the primary reason for why jQuery still needs its auto-prefixing feature of the `.css()` method. And probably the most popular (the only?) widely supported CSS property that still needs a prefix in a major browser. It'd be good to get it fixed.