242006 2022-06-25 13:35:31 -0700 -webkit-user-select: all should not affect editability 2025-10-24 09:48:00 -0700 1 1 1 Unclassified WebKit HTML Editing WebKit Nightly Build Unspecified Unspecified NEW https://bugs.webkit.org/show_bug.cgi?id=242366 InRadar P2 Normal --- 208677 1 wenson_hsieh webkit-unassigned emilio jarek karlcow m.goleb+bugzilla ntim rniwa webkit-bug-importer wenson_hsieh oldest_to_newest 1878382 0 wenson_hsieh 2022-06-25 13:35:31 -0700 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`. 1878384 1 460492 wenson_hsieh 2022-06-25 13:39:20 -0700 Created attachment 460492 Test case 1878386 2 wenson_hsieh 2022-06-25 13:42:00 -0700 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. 1878387 3 wenson_hsieh 2022-06-25 13:42:35 -0700 (In reply to Wenson Hsieh from comment #2) > We could attempt to default to `UserSelectAllIsAlwaysNonEditable` in more ..I meant to write `UserSelectAllDoesNotAffectEditability`, of course :) 1878388 4 rniwa 2022-06-25 13:57:18 -0700 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`. 1878396 5 ntim 2022-06-25 14:33:49 -0700 (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`). 1878398 6 rniwa 2022-06-25 15:04:35 -0700 (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. 1878401 7 ntim 2022-06-25 16:11:48 -0700 (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. 1878435 8 460498 karlcow 2022-06-26 20:09:41 -0700 Created attachment 460498 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) 1878437 9 460499 karlcow 2022-06-26 21:32:36 -0700 Created attachment 460499 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> ``` 1878438 10 rniwa 2022-06-26 21:40:43 -0700 (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. 1878446 11 karlcow 2022-06-26 22:47:44 -0700 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 1880791 12 ntim 2022-07-05 13:59:04 -0700 Pull request: https://github.com/WebKit/WebKit/pull/2094 1880838 13 ntim 2022-07-05 16:15:07 -0700 Keeping this bug since it has more information, but going to fix the original bug by reverting. 1880840 14 ntim 2022-07-05 16:19:03 -0700 Bug 242366 reverts unprefixing 1880886 15 rniwa 2022-07-05 20:39:05 -0700 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. 2154053 16 m.goleb+bugzilla 2025-10-24 09:48:00 -0700 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. 460492 2022-06-25 13:39:20 -0700 2022-06-25 13:39:20 -0700 Test case user-select-all.html text/html 67 wenson_hsieh PGRpdiBjb250ZW50ZWRpdGFibGUgc3R5bGU9InVzZXItc2VsZWN0OiBhbGw7Ij5UcnkgdG8gZWRp dCBtZTwvZGl2Pg== 460498 2022-06-26 20:09:41 -0700 2022-06-26 20:09:41 -0700 test with different cases for cross testing browsers. test-user-select.html text/html 810 karlcow PCFET0NUWVBFIGh0bWw+CjxodG1sIGxhbmc9ImVuIj4KPGhlYWQ+CiAgICA8bWV0YSBjaGFyc2V0 PSJVVEYtOCI+CiAgICA8bWV0YSBodHRwLWVxdWl2PSJYLVVBLUNvbXBhdGlibGUiIGNvbnRlbnQ9 IklFPWVkZ2UiPgogICAgPG1ldGEgbmFtZT0idmlld3BvcnQiIGNvbnRlbnQ9IndpZHRoPWRldmlj ZS13aWR0aCwgaW5pdGlhbC1zY2FsZT0xLjAiPgogICAgPHRpdGxlPlRlc3QgdXNlci1zZWxlY3Qg Y29tYmluYXRpb248L3RpdGxlPgo8L2hlYWQ+Cjxib2R5Pgo8YSBocmVmPSJodHRwczovL2J1Z3Mu d2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MjQyMDA2Ij5idWcgMjQyMDA2PC9hPiAtIENhbm5v dCBlZGl0IGNvbXBvc2UgYm9keSBmaWVsZCBvbiBvdXRsb29rLmNvbQoKPGgxPjxjb2RlPi13ZWJr aXQtdXNlci1zZWxlY3Q6YXV0bzt1c2VyLXNlbGVjdDogYWxsOzwvY29kZT4gLSBvdXRsb29rIGJy ZWFrYWdlPC9oMT4KPGRpdiBjb250ZW50ZWRpdGFibGUgc3R5bGU9Ii13ZWJraXQtdXNlci1zZWxl Y3Q6YXV0bzt1c2VyLXNlbGVjdDogYWxsOyI+VHJ5IHRvIGVkaXQgbWU8L2Rpdj4KCjxoMT48Y29k ZT51c2VyLXNlbGVjdDogYWxsOzwvY29kZT48L2gxPgo8ZGl2IGNvbnRlbnRlZGl0YWJsZSBzdHls ZT0idXNlci1zZWxlY3Q6IGFsbDsiPlRyeSB0byBlZGl0IG1lPC9kaXY+Cgo8aDE+PGNvZGU+LXdl YmtpdC11c2VyLXNlbGVjdDphdXRvOzwvY29kZT48L2gxPgo8ZGl2IGNvbnRlbnRlZGl0YWJsZSBz dHlsZT0iLXdlYmtpdC11c2VyLXNlbGVjdDphdXRvOyI+VHJ5IHRvIGVkaXQgbWU8L2Rpdj4KPC9i b2R5Pgo8L2h0bWw+ 460499 2022-06-26 21:32:36 -0700 2022-06-26 21:32:36 -0700 actual markup from outlook outlook-code-safari.html text/html 480 karlcow PGRpdgogIGlkPSJlZGl0b3JEaXYiCiAgYXJpYS1tdWx0aWxpbmU9InRydWUiCiAgcm9sZT0idGV4 dGJveCIKICBjb250ZW50ZWRpdGFibGU9InRydWUiCiAgY2xhc3M9Il8yVHk4RWpJU283NWJzQ0dP d3prNzk1IgogIHNwZWxsY2hlY2s9ImZhbHNlIgogIGFyaWEtbGFiZWw9Ik1lc3NhZ2U6ICIKPgog IDxkaXY+CiAgICA8c3BhbgogICAgICBpZD0iX3Jvb3N0ZXJfd2F0ZXJtYXJrU3BhbiIKICAgICAg PlR5cGUgJ0AnIHRvIG1lbnRpb24gc29tZW9uZTwvc3BhbgogICAgPgogIDwvZGl2Pgo8L2Rpdj4K CjxzdHlsZT4KICAuXzJUeThFaklTbzc1YnNDR093ems3OTUgewogICAgLXdlYmtpdC11c2VyLXNl bGVjdDogYXV0bzsKICAgIC1tcy11c2VyLXNlbGVjdDogYWxsOwogICAgdXNlci1zZWxlY3Q6IGFs bDsKICAgIC1tb3otdXNlci1zZWxlY3Q6IHRleHQ7CiAgICAtd2Via2l0LXVzZXItbW9kaWZ5OiBy ZWFkLXdyaXRlOwogIH0KPC9zdHlsZT4K