211994 2020-05-17 03:08:21 -0700 MobileSafari falsely claims CSS resize property support 2022-05-18 05:23:30 -0700 1 1 1 Unclassified WebKit CSS WebKit Nightly Build Unspecified iOS 13 NEW https://bugs.webkit.org/show_bug.cgi?id=210473 InRadar P2 Normal --- 1 bramus webkit-unassigned gsnedders koivisto mjs ntim simon.fraser tomac webkit-bug-importer wenson_hsieh zalan oldest_to_newest 1653396 0 bramus 2020-05-17 03:08:21 -0700 Recently I wrote an article on using CSS `resize: both;`: https://www.bram.us/2020/05/15/css-only-resizable-elements/ In browsers that don't support this property I wanted to show a warning on screen to notify users thereof. For this I use an @supports rule: ```css .warning { display: block; } /* Hide warning in case browser supports resize: both; */ @supports (resize: both) { .warning { display: none; } } ``` I've come to notice that MobileSafari – which does not support `resize: both;` – hides the warning and thus falsely claims to support said CSS resize property. Demo: https://codepen.io/bramus/pen/RwWeqOP 1653549 1 webkit-bug-importer 2020-05-18 03:48:02 -0700 <rdar://problem/63335059> 1868870 2 ntim 2022-05-13 14:55:29 -0700 The CSS property is technically detected/understood by the engine on mobile. It's just that we decide to hide the resizer on mobile. 1868888 3 gsnedders 2022-05-13 15:24:06 -0700 (In reply to Tim Nguyen (:ntim) from comment #2) > The CSS property is technically detected/understood by the engine on mobile. > It's just that we decide to hide the resizer on mobile. Who owns the resizer? It seems like the resizer and the property should both be linked to a single setting if WebKit owns it. 1868911 4 ntim 2022-05-13 16:31:08 -0700 The resizer is implemented in RenderLayer.cpp (see canResize() and friends). But yeah I agree, the best way to make supports work properly is to guard the CSS property behind a flag. 1868935 5 gsnedders 2022-05-13 18:24:48 -0700 (In reply to Tim Nguyen (:ntim) from comment #4) > The resizer is implemented in RenderLayer.cpp (see canResize() and friends). > > But yeah I agree, the best way to make supports work properly is to guard > the CSS property behind a flag. I… actually knew that. I guess my question was more "what hides it on mobile", or causes it to not be painted? Is it simply that they don't have a layer or something? 1868966 6 ntim 2022-05-14 00:00:37 -0700 (In reply to Sam Sneddon [:gsnedders] from comment #5) > (In reply to Tim Nguyen (:ntim) from comment #4) > > The resizer is implemented in RenderLayer.cpp (see canResize() and friends). > > > > But yeah I agree, the best way to make supports work properly is to guard > > the CSS property behind a flag. > > I… actually knew that. I guess my question was more "what hides it on > mobile", or causes it to not be painted? Is it simply that they don't have a > layer or something? No idea, maybe Simon can answer? 1869016 7 simon.fraser 2022-05-14 10:47:16 -0700 I think the primary issue here is that we'd need to implement some touch event handling on iOS to actually support user interaction with the resize. That was never done, so early in iOS development it was decided to just not paint the resize. 1869623 8 gsnedders 2022-05-17 02:31:28 -0700 Ah, it's BuilderConverter::convertResize which contains the check, and the TextAreasAreResizable setting. We probably just want to gate the resize property on that setting. 1869963 9 ntim 2022-05-18 05:23:30 -0700 (In reply to Sam Sneddon [:gsnedders] from comment #8) > Ah, it's BuilderConverter::convertResize which contains the check, and the > TextAreasAreResizable setting. We probably just want to gate the resize > property on that setting. The check in that function is only for `resize: auto` (a non-standard value fwiw), this bug is about `resize: both`.