WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
242006
-webkit-user-select: all should not affect editability
https://bugs.webkit.org/show_bug.cgi?id=242006
Summary
-webkit-user-select: all should not affect editability
Wenson Hsieh
Reported
2022-06-25 13:35:31 PDT
rdar://94619119
Steps: 1. Go to outlook.live.com on iOS 16. 2. Click (+) to compose a new email 3. Try to focus the body field to begin typing. Expected: the user should be able to compose an email. Observed: the body field isn't editable. Regressed after unprefixing `user-select: all;`. The contenteditable div representing the body field has these CSS properties: ``` -webkit-user-select: auto; user-select: all; ``` Before unprefixing `user-select`, we were using the `auto` behavior specified via `-webkit-user-select`.
Attachments
Test case
(67 bytes, text/html)
2022-06-25 13:39 PDT
,
Wenson Hsieh
no flags
Details
test with different cases for cross testing browsers.
(810 bytes, text/html)
2022-06-26 20:09 PDT
,
Karl Dubost
no flags
Details
actual markup from outlook
(480 bytes, text/html)
2022-06-26 21:32 PDT
,
Karl Dubost
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Wenson Hsieh
Comment 1
2022-06-25 13:39:20 PDT
Created
attachment 460492
[details]
Test case
Wenson Hsieh
Comment 2
2022-06-25 13:42:00 PDT
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.
Wenson Hsieh
Comment 3
2022-06-25 13:42:35 PDT
(In reply to Wenson Hsieh from
comment #2
)
> We could attempt to default to `UserSelectAllIsAlwaysNonEditable` in more
..I meant to write `UserSelectAllDoesNotAffectEditability`, of course :)
Ryosuke Niwa
Comment 4
2022-06-25 13:57:18 PDT
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`.
Tim Nguyen (:ntim)
Comment 5
2022-06-25 14:33:49 PDT
(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`).
Ryosuke Niwa
Comment 6
2022-06-25 15:04:35 PDT
(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.
Tim Nguyen (:ntim)
Comment 7
2022-06-25 16:11:48 PDT
(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.
Karl Dubost
Comment 8
2022-06-26 20:09:41 PDT
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)
Karl Dubost
Comment 9
2022-06-26 21:32:36 PDT
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> ```
Ryosuke Niwa
Comment 10
2022-06-26 21:40:43 PDT
(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.
Karl Dubost
Comment 11
2022-06-26 22:47:44 PDT
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
Tim Nguyen (:ntim)
Comment 12
2022-07-05 13:59:04 PDT
Pull request:
https://github.com/WebKit/WebKit/pull/2094
Tim Nguyen (:ntim)
Comment 13
2022-07-05 16:15:07 PDT
Keeping this bug since it has more information, but going to fix the original bug by reverting.
Tim Nguyen (:ntim)
Comment 14
2022-07-05 16:19:03 PDT
Bug 242366
reverts unprefixing
Ryosuke Niwa
Comment 15
2022-07-05 20:39:05 PDT
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.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug