199691 2019-07-10 16:37:25 -0700 The whole viewport shifts down when resetting document scrollTop 2020-04-20 18:58:05 -0700 1 1 1 Unclassified WebKit HTML Editing Safari Technology Preview Unspecified Unspecified NEW https://bugs.webkit.org/show_bug.cgi?id=198737 https://bugs.webkit.org/show_bug.cgi?id=198599 https://bugs.webkit.org/show_bug.cgi?id=198598 https://bugs.webkit.org/show_bug.cgi?id=198597 InRadar P2 Normal --- 1 xidorn-webkit webkit-unassigned fred.wang rniwa simon.fraser thorton webkit-bug-importer wenson_hsieh oldest_to_newest 1551882 0 373876 xidorn-webkit 2019-07-10 16:37:25 -0700 Created attachment 373876 testcase Steps to reproduce: 1. open the attached testcase on iOS 2. tap the "Hello world" text Expect result: The keyboard shows up without moving the viewport. Actual result: The whole viewport briefly shifts down. In this testcase, the page tries to move the text up manually (for various reasons), thus it wants to remove the scrolling on document done by the browser. But that triggers this issue. The effect is similar to bug 198737, and this is probably the actual cause of that issue. This is reproducible on both iOS 12 and iOS 13. Similar to bug 198737, you can see this shift clearer via using simulators with Debug / Slow Animations enabled. 1552161 1 webkit-bug-importer 2019-07-11 12:50:14 -0700 <rdar://problem/52966595> 1552569 2 rniwa 2019-07-12 15:42:30 -0700 The scrolling in iOS is asynchronous. By the time scroll event is fired, the scrolling had already happened asynchronously so that's too late. 1552599 3 simon.fraser 2019-07-12 16:21:55 -0700 document.addEventListener('scroll', evt => { document.documentElement.scrollTop = 0; document.body.scrollTop = 0; }); This is a really bad pattern that we see commonly; if you rubber-band the content, it will also try to set the scrollTop back to 0. 1552728 4 xidorn-webkit 2019-07-13 21:27:01 -0700 (In reply to Simon Fraser (smfr) from comment #3) > document.addEventListener('scroll', evt => { > document.documentElement.scrollTop = 0; > document.body.scrollTop = 0; > }); > > This is a really bad pattern that we see commonly; if you rubber-band the > content, it will also try to set the scrollTop back to 0. I feel like this is potentially an anti-pattern, but how would you recommend for the case where author may want to move the element manually, for example, when they want to zoom to the current visible area? 1552763 5 rniwa 2019-07-14 14:45:16 -0700 (In reply to Xidorn Quan from comment #4) > (In reply to Simon Fraser (smfr) from comment #3) > > document.addEventListener('scroll', evt => { > > document.documentElement.scrollTop = 0; > > document.body.scrollTop = 0; > > }); > > > > This is a really bad pattern that we see commonly; if you rubber-band the > > content, it will also try to set the scrollTop back to 0. > > I feel like this is potentially an anti-pattern, but how would you recommend > for the case where author may want to move the element manually, for > example, when they want to zoom to the current visible area? The recommended approach is to move the element immediately when the input element is focused so the WebKit wouldn't try to scroll to it. In general, once the keyboard has started being brought up, there is nothing you can do to cancel the scrolling. 1552778 6 xidorn-webkit 2019-07-14 17:18:53 -0700 > The recommended approach is to move the element immediately when the input element is focused so the WebKit wouldn't try to scroll to it. Thanks for the advice. It's not always trivial to do in practice, but I guess it's not impossible either. I wonder, though, why would resetting the scrollTop makes the viewport shift down while we are just trying to stop it from shifting up? 1553052 7 xidorn-webkit 2019-07-15 17:39:17 -0700 (In reply to Ryosuke Niwa from comment #5) > The recommended approach is to move the element immediately when the input > element is focused so the WebKit wouldn't try to scroll to it. Actually, this approach doesn't seem to work either. As shown in this testcase, I do move the element immediately when it's focused, and it just has a transition to do so smoothly. Even if I remove the transition (so that the moving happens immediately in handler of focus event in any sense), the viewport still scroll. 1628545 8 rniwa 2020-03-10 23:21:53 -0700 (In reply to Xidorn Quan from comment #7) > (In reply to Ryosuke Niwa from comment #5) > > The recommended approach is to move the element immediately when the input > > element is focused so the WebKit wouldn't try to scroll to it. > > Actually, this approach doesn't seem to work either. > > As shown in this testcase, I do move the element immediately when it's > focused, and it just has a transition to do so smoothly. > > Even if I remove the transition (so that the moving happens immediately in > handler of focus event in any sense), the viewport still scroll. Hm... is this still an issue in the latest betas of iOS 13.4? 1643728 9 xidorn-webkit 2020-04-20 18:58:05 -0700 (In reply to Ryosuke Niwa from comment #8) > Hm... is this still an issue in the latest betas of iOS 13.4? Sorry for the late reply. I didn't get a chance to test on the beta version, but it still seems to be an issue on the latest 13.4.1. 373876 2019-07-10 16:37:25 -0700 2019-07-10 16:37:25 -0700 testcase transform-text.html text/html 971 xidorn-webkit PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8bWV0YSBuYW1lPSJ2aWV3cG9ydCIgY29udGVudD0id2lk dGg9ZGV2aWNlLXdpZHRoLCBpbml0aWFsLXNjYWxlPTEsIG1pbmltdW0tc2NhbGU9MSwgbWF4aW11 bS1zY2FsZT0xLCB1c2VyLXNjYWxhYmxlPW5vLCB2aWV3cG9ydC1maXQ9Y292ZXIiPgo8c3R5bGU+ Cmh0bWwsIGJvZHksIC5jb250YWluZXIgewogIHdpZHRoOiAxMDAlOwogIGhlaWdodDogMTAwJTsK ICBtYXJnaW46IDA7Cn0KLmNvbnRhaW5lciB7CiAgYm94LXNpemluZzogYm9yZGVyLWJveDsKICBi YWNrZ3JvdW5kOiBwaW5rOwogIHBhZGRpbmc6IDAgMjBweDsKfQouaW5uZXIgewogIHdpZHRoOiAx MDBweDsKICB0cmFuc2l0aW9uOiB0cmFuc2Zvcm0gMjAwbXM7CiAgdHJhbnNmb3JtOiB0cmFuc2xh dGUoMCwgNTAwcHgpOwp9Ci5lZGl0aW5nIHsKICB0cmFuc2Zvcm06IHRyYW5zbGF0ZSgwLCAxMDBw eCk7Cn0KPC9zdHlsZT4KPGRpdiBjbGFzcz0iY29udGFpbmVyIj4KICA8ZGl2IGNsYXNzPSJpbm5l ciI+CiAgICA8ZGl2IGNvbnRlbnRlZGl0YWJsZT5IZWxsbyB3b3JsZDwvZGl2PgogIDwvZGl2Pgo8 L2Rpdj4KPHNjcmlwdD4KY29uc3QgaW5uZXIgPSBkb2N1bWVudC5xdWVyeVNlbGVjdG9yKCcuaW5u ZXInKTsKY29uc3QgZWRpdG9yID0gZG9jdW1lbnQucXVlcnlTZWxlY3RvcignW2NvbnRlbnRlZGl0 YWJsZV0nKTsKZG9jdW1lbnQuYWRkRXZlbnRMaXN0ZW5lcignc2Nyb2xsJywgZXZ0ID0+IHsKICBk b2N1bWVudC5kb2N1bWVudEVsZW1lbnQuc2Nyb2xsVG9wID0gMDsKICBkb2N1bWVudC5ib2R5LnNj cm9sbFRvcCA9IDA7Cn0pOwplZGl0b3IuYWRkRXZlbnRMaXN0ZW5lcignZm9jdXMnLCAoKSA9PiBp bm5lci5jbGFzc0xpc3QuYWRkKCdlZGl0aW5nJykpOwplZGl0b3IuYWRkRXZlbnRMaXN0ZW5lcign Ymx1cicsICgpID0+IGlubmVyLmNsYXNzTGlzdC5yZW1vdmUoJ2VkaXRpbmcnKSk7Cjwvc2NyaXB0 Pgo=