138201 2014-10-29 17:45:22 -0700 Caret doesn't move while scrolling -webkit-overflow-scrolling: touch content on iOS 2022-03-10 10:13:52 -0800 1 1 1 Unclassified WebKit Forms Safari 9 iPhone / iPad iOS 10 NEW https://bugs.webkit.org/show_bug.cgi?id=179927 https://bugs.webkit.org/show_bug.cgi?id=202125 http://output.jsbin.com/hoxuxu HasReduction, InRadar P2 Normal --- 159753 1 webkit megan_gardner ae ajuma ap carlos ccorcos dbates enrica fgoeb fred.wang gabrielmaldi gaston.avila hans.oksendahl hnrch02+webkit icewil info js.magoon peter.koshelev pikatore piotr pleger2 q2224859 samtsai selim simon.fraser vitaly.kosenko webkit-bug-importer wenson_hsieh xenonelive oldest_to_newest 1044928 0 webkit 2014-10-29 17:45:22 -0700 Original Bootstrap bug: https://github.com/twbs/bootstrap/issues/14708 1. Open http://jsbin.com/himir/2 in iOS 8 Safari. 2. Click the green button 3. Tap into the "First Name" text field 4. Place finger on part of the empty white background of the modal form box 5. Move your finger upwards so as to scroll the modal down, but don't take your finger off of the screen. Actual Result: Observe that the blinking blue text cursor remains at its original location before the scrolling began. Expected Result: Either the cursor should move along with the text field or it should temporarily stop being displayed altogether. This bug has been reproduced on iOS 7 and iOS 8. 1044932 1 webkit 2014-10-29 17:55:52 -0700 Have also filed this as: <rdar://problem/18819624> 1092300 2 252514 webkit 2015-05-06 13:40:02 -0700 Created attachment 252514 Copy of 1st JS Bin example 1137831 3 webkit 2015-10-30 01:20:15 -0700 I am unable to re-test the testcase against iOS 9 since it's affected by bug 150715. 1162797 4 webkit 2016-02-07 16:40:47 -0800 Updated testcase to avoid bug 150715. 1162798 5 webkit 2016-02-07 16:41:53 -0800 I can't reproduce this in iOS 9.2. 1163125 6 pikatore 2016-02-08 19:16:21 -0800 I can. Please reopen the issue. A good example of a site this issue occurs on: https://material.angularjs.org/latest/demo/input Issue occurs in Safari, WKWebKit view iOS 9.2.1 1163130 7 webkit 2016-02-08 19:32:53 -0800 Interesting. Confirmed. 1167922 8 pikatore 2016-02-24 14:31:49 -0800 Not one to be a nag, but I think this bug is a pretty serious usability issue. It's a deal breaker in creating SPAs for iOS, which is becoming an increasing trend. What is this issue most probably due to? 1173482 9 pikatore 2016-03-10 17:24:28 -0800 Are there are any known workaround to this? It's driving me insane and my users are constantly complaining about it. 1173671 10 carlos 2016-03-11 02:17:02 -0800 I have spent some days trying to find a workaround without success. Here there is a gif when we can see the caret floating when scrolling https://media.giphy.com/media/3o7abrmGRJeHg0PYZy/giphy.gif Things I know: - still happening in iOS 9.3 - Only happens when the scroll is not in the body. Usually to have a fixed layer like a header. - Only happens when -webkit-overflow-scrolling: touch is activated (for able to scroll with momentum) 1173673 11 webkit 2016-03-11 02:24:03 -0800 Carlos, could you post the URL of your JS Bin? Looks like it might be a simpler (and thus better) testcase than the current AngularJS one. 1173674 12 carlos 2016-03-11 02:31:43 -0800 http://output.jsbin.com/hoxuxu http://jsbin.com/hoxuxu/edit?html,css,output Also, here is another issue with the caret and scroll that maybe is related and can help. https://stackoverflow.com/questions/35700636/input-caret-floating-over-a-fixed-layer-when-scrolling Thanks 1175238 13 pikatore 2016-03-15 18:40:48 -0700 I should add: My input fields use transform3D(0,0,0) as a workaround to fix the safari disappearing fields bug: http://stackoverflow.com/questions/9807620/ipad-safari-scrolling-causes-html-elements-to-disappear-and-reappear-with-a-dela This may or may not be a contributing factor. It's incredible that this is still a problem! 1175239 14 pikatore 2016-03-15 18:42:47 -0700 I've run into it again in another scenario... http://stackoverflow.com/questions/20737503/mobile-safari-input-caret-does-not-scroll-along-with-overflow-scrolling-touch This issue needs WAY more attention. 1175243 15 simon.fraser 2016-03-15 18:47:52 -0700 (In reply to comment #14) > I've run into it again in another scenario... > > http://stackoverflow.com/questions/20737503/mobile-safari-input-caret-does- > not-scroll-along-with-overflow-scrolling-touch Did you file a bug on that issue? 1175244 16 pikatore 2016-03-15 18:48:41 -0700 In Apple's bug reporter? Yes. Months ago. 1175245 17 simon.fraser 2016-03-15 18:49:55 -0700 Can you comment with the bug number please. 1175246 18 pikatore 2016-03-15 18:50:48 -0700 24882755 1175249 19 simon.fraser 2016-03-15 19:01:14 -0700 (In reply to comment #18) > 24882755 Thank you. I'll look into it. 1175272 20 pikatore 2016-03-15 21:29:13 -0700 Found a workaround! This workaround is partially in angular.js but should work with any JS framework (or pure JS). On tapping an input field, I used $location.hash to jump to the field above it straight after focus, which caused the input cursor to stay where it was. If I just trigger a .blur() then a focus() about 300-400 ms after the scroll jumped, the input cursor 'reset' its position to the correct one. 1329955 21 vitaly.kosenko 2017-07-18 04:27:19 -0700 Why do I still see error in Safari 10 on iOS 10.3.2 in http://jsfiddle.net/gxT3w. I'am setting focus and start scrolling 1355897 22 gabrielmaldi 2017-10-03 10:58:30 -0700 I can still repro this issue in UIWebView on iOS 11.1. 1359273 23 simon.fraser 2017-10-11 11:30:39 -0700 Does it reproduce in WKWebView? 1359893 24 gabrielmaldi 2017-10-12 19:20:39 -0700 (In reply to Simon Fraser (smfr) from comment #23) > Does it reproduce in WKWebView? Yes, it does. I just tested the following code on my iPhone 6S running iOS 11.1 beta 2: ``` WKWebView *webView = [[WKWebView alloc] init]; NSURL *url = [NSURL URLWithString:@"https://jsfiddle.net/gabrielmaldi/n5pgedzv/show/"]; NSURLRequest *request = [NSURLRequest requestWithURL:url]; [webView loadRequest:request]; ``` And this is the result: https://youtu.be/KYBOEePlysk Even though it repros in WKWebView, native web apps have no option but to use the older UIWebView because WKWebView doesn't handle local files well (and a web server is needed). So it would be great if this issue got fixed and also backported to UIWebView. Thanks 1360756 25 q2224859 2017-10-16 07:59:38 -0700 How is this issue not resolved yet? Seriously. As carlos already issued at 2016-03-11 (WTF): - still happening in iOS 9.3 - Only happens when the scroll is not in the body. Usually to have a fixed layer like a header. - Only happens when -webkit-overflow-scrolling: touch is activated (for able to scroll with momentum) 1361563 26 simon.fraser 2017-10-17 20:52:43 -0700 With both UIWebView and WKWebView on iOS 11, I can reproduce the caret remaining visible when scrolling on https://jsfiddle.net/gabrielmaldi/n5pgedzv/show/. However, in both cases when the scroll ends the caret snaps to the correct location. 1361564 27 simon.fraser 2017-10-17 20:58:19 -0700 We need to track when the caret is inside accelerated overflow scroll and just hide it while scrolling, as we do inside position:fixed (see -shouldHideSelectionWhenScrolling). 1369566 28 hans.oksendahl 2017-11-08 13:45:02 -0800 It has been quite a while since this bug was reported is there an ETA for a fix? While this bug does not prevent the user from inputting using the onscreen keyboard it does break the expected user interaction and I believe it should be considered a P1. 1376066 29 js.magoon 2017-11-29 15:23:23 -0800 Would love for this bug to get some attention. Our users complain about it due to not knowing where text is going to get entered until a user starts typing or performs another action on the site. 1452913 34 gabrielmaldi 2018-08-22 17:49:10 -0700 Just confirmed the issue exists in iOS 12 developer beta 9, running on my iPhone X using Xcode 10 beta 6. Same code and behavior (YouTube video) I posted in [Comment 24](https://bugs.webkit.org/show_bug.cgi?id=138201#c24) for both WKWebView and UIWebView. 1469942 35 ccorcos 2018-10-16 16:41:47 -0700 I'm having this same issue. Looks like a native re-rendering problem. If I listen to the "scroll" event and change `paddingBottom = Math.random() + "px"` causing a re-render, then the caret moves. The view also janks around though too. Not a solution, just a demonstration. Please fix this Apple! :) 1469961 36 ccorcos 2018-10-16 17:03:24 -0700 I have a really hacky solution that appears to work in the meantime. It takes a toll on performance though :/ ``` import * as raf from "raf" let elm: HTMLDivElement | undefined function getElm() { if (!elm) { elm = document.createElement("div") elm.style.position = "fixed" elm.style.top = "-9999px" elm.style.left = "-9999px" elm.style.zIndex = "-9999" document.body.appendChild(elm) } return elm } let pendingRender = false function forceRerender() { if (pendingRender) { return } pendingRender = true raf(() => { pendingRender = false getElm().style.height = Math.random() + "px" }) } function rerenderSelectionCaret() { if (window.getSelection().anchorNode) { forceRerender() } } // get your scroller element scroller.addEventListener("scroll", rerenderSelectionCaret) ``` 1475941 37 info 2018-11-07 03:19:28 -0800 In our case, this even prevented form field values from being rendered. You can see the caret moving but no text is shown. Querying the field's value properly returns the entered text. By forcing a re-render, e.g. by changing CSS properties of the field, the value is rendered then. This is really a major issue. We've tested it on the latest versions of iOS 11 and 12. Removing "-webkit-overflow-scrolling" solves the rendering issue but sacrifices UX. 1475944 38 info 2018-11-07 03:26:26 -0800 (In reply to Mato from comment #37) > In our case, this even prevented form field values from being rendered. You > can see the caret moving but no text is shown. Querying the field's value > properly returns the entered text. By forcing a re-render, e.g. by changing > CSS properties of the field, the value is rendered then. > > This is really a major issue. We've tested it on the latest versions of iOS > 11 and 12. Removing "-webkit-overflow-scrolling" solves the rendering issue > but sacrifices UX. An additional information I forgot to mention is, that we're experiencing this issue in both, Safari and WkWebView. 1476059 39 simon.fraser 2018-11-07 10:45:58 -0800 (In reply to Mato from comment #37) > In our case, this even prevented form field values from being rendered. You > can see the caret moving but no text is shown. Querying the field's value > properly returns the entered text. By forcing a re-render, e.g. by changing > CSS properties of the field, the value is rendered then. That sounds like a separate issue. Can you file a new bug with a test case? 1583702 40 piotr 2019-10-25 00:18:16 -0700 Still experiencing this in iOS 13.1.3 in WKWebView and Safari. Haven´t been able to find any workaround. Tried using the scroll event to hide the caret, re-rendering the field by setting value to something else and then back again on scroll did help a little bit but broke the bouncy scroll. So stuck with a glitchy app. 1850149 41 peter.koshelev 2022-03-10 10:13:52 -0800 any solution for this!? 252514 2015-05-06 13:40:02 -0700 2016-03-11 02:36:54 -0800 Copy of 1st JS Bin example example-himir-2.html text/html 3405 webkit PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8aGVhZD48bWV0YSBuYW1lPSJyb2JvdHMiIGNvbnRlbnQ9 Im5vaW5kZXgiPgoKICAgIDx0aXRsZT5Cb290c3RyYXAgMyBDb250YWN0IE1vZGFsPC90aXRsZT4K ICAgIDxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lkdGgsIGlu aXRpYWwtc2NhbGU9MS4wIj4KICAgIAogICAgPCEtLSBCb290c3RyYXAgY29yZSBDU1MgLS0+CiAg ICA8bGluayBocmVmPSJodHRwOi8vY2RuanMuY2xvdWRmbGFyZS5jb20vYWpheC9saWJzL3R3aXR0 ZXItYm9vdHN0cmFwLzMuMi4wL2Nzcy9ib290c3RyYXAuY3NzIiByZWw9InN0eWxlc2hlZXQiIG1l ZGlhPSJzY3JlZW4iPgo8L2hlYWQ+Cjxib2R5Pgo8ZGl2IGNsYXNzPSJjb250YWluZXIiPgogICAg PCEtLSBCdXR0b24gdG8gdHJpZ2dlciBtb2RhbCAtLT4gCiAgICA8YSBocmVmPSIjbXlNb2RhbCIg cm9sZT0iYnV0dG9uIiBjbGFzcz0iYnRuIGJ0bi1zdWNjZXNzIiBkYXRhLXRvZ2dsZT0ibW9kYWwi Pk9wZW4gQ29udGFjdCBGb3JtPC9hPgogICAgPCEtLSBNb2RhbCAtLT4KICAgIDxkaXYgaWQ9Im15 TW9kYWwiIGNsYXNzPSJtb2RhbCBmYWRlIiB0YWJpbmRleD0iLTEiIHJvbGU9ImRpYWxvZyIgYXJp YS1sYWJlbGxlZGJ5PSJteU1vZGFsTGFiZWwiIGFyaWEtaGlkZGVuPSJ0cnVlIj4KICAgICAgICA8 ZGl2IGNsYXNzPSJtb2RhbC1kaWFsb2ciPgogICAgICAgIDxkaXYgY2xhc3M9Im1vZGFsLWNvbnRl bnQiPgogICAgICAgIDxkaXYgY2xhc3M9Im1vZGFsLWhlYWRlciI+CiAgICAgICAgICAgIDxidXR0 b24gdHlwZT0iYnV0dG9uIiBjbGFzcz0iY2xvc2UiIGRhdGEtZGlzbWlzcz0ibW9kYWwiIGFyaWEt aGlkZGVuPSJ0cnVlIj7DlzwvYnV0dG9uPgogICAgICAgICAgICA8aDQgY2xhc3M9Im1vZGFsLXRp dGxlIj5Db250YWN0IEZvcm08L2g0PgogICAgICAgIDwvZGl2PgogICAgICAgIDxkaXYgY2xhc3M9 Im1vZGFsLWJvZHkiPgogICAgICAgICAgICA8Zm9ybSBjbGFzcz0iZm9ybS1ob3Jpem9udGFsIiBu YW1lPSJjb21tZW50Zm9ybSIgbWV0aG9kPSJwb3N0IiBhY3Rpb249InNlbmRfZm9ybV9lbWFpbF9z bGVlcF9yZS5waHAiPgogICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZm9ybS1ncm91cCI+CiAg ICAgICAgICAgICAgICAgICAgPGxhYmVsIGNsYXNzPSJjb250cm9sLWxhYmVsIGNvbC1tZC00IiBm b3I9ImZpcnN0X25hbWUiPkZpcnN0IE5hbWU8L2xhYmVsPgogICAgICAgICAgICAgICAgICAgIDxk aXYgY2xhc3M9ImNvbC1tZC02Ij4KICAgICAgICAgICAgICAgICAgICAJPGlucHV0IHR5cGU9InRl eHQiIGNsYXNzPSJmb3JtLWNvbnRyb2wiIGlkPSJmaXJzdF9uYW1lIiBuYW1lPSJmaXJzdF9uYW1l IiBwbGFjZWhvbGRlcj0iRmlyc3QgTmFtZSI+CiAgICAgICAgICAgICAgICAgICAgPC9kaXY+CiAg ICAgICAgICAgICAgICA8L2Rpdj4KICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImZvcm0tZ3Jv dXAiPgogICAgICAgICAgICAgICAgICAgIDxsYWJlbCBjbGFzcz0iY29udHJvbC1sYWJlbCBjb2wt bWQtNCIgZm9yPSJsYXN0X25hbWUiPkxhc3QgTmFtZTwvbGFiZWw+CiAgICAgICAgICAgICAgICAg ICAgPGRpdiBjbGFzcz0iY29sLW1kLTYiPgogICAgICAgICAgICAgICAgICAgICAgICA8aW5wdXQg dHlwZT0idGV4dCIgY2xhc3M9ImZvcm0tY29udHJvbCIgaWQ9Imxhc3RfbmFtZSIgbmFtZT0ibGFz dF9uYW1lIiBwbGFjZWhvbGRlcj0iTGFzdCBOYW1lIj4KICAgICAgICAgICAgICAgICAgICA8L2Rp dj4KICAgICAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZm9y bS1ncm91cCI+CiAgICAgICAgICAgICAgICAgICAgPGxhYmVsIGNsYXNzPSJjb250cm9sLWxhYmVs IGNvbC1tZC00IiBmb3I9ImVtYWlsIj5FbWFpbCBBZGRyZXNzPC9sYWJlbD4KICAgICAgICAgICAg ICAgICAgICA8ZGl2IGNsYXNzPSJjb2wtbWQtNiBpbnB1dC1ncm91cCI+CiAgICAgICAgICAgICAg ICAgICAgPHNwYW4gY2xhc3M9ImlucHV0LWdyb3VwLWFkZG9uIj5APC9zcGFuPgoJCQkJCQk8aW5w dXQgdHlwZT0iZW1haWwiIGNsYXNzPSJmb3JtLWNvbnRyb2wiIGlkPSJlbWFpbCIgbmFtZT0iZW1h aWwiIHBsYWNlaG9sZGVyPSJFbWFpbCBBZGRyZXNzIj4KICAgICAgICAgICAgICAgICAgICA8L2Rp dj4KICAgICAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZm9y bS1ncm91cCI+CiAgICAgICAgICAgICAgICAgICAgPGxhYmVsIGNsYXNzPSJjb250cm9sLWxhYmVs IGNvbC1tZC00IiBmb3I9ImNvbW1lbnQiPlF1ZXN0aW9uIG9yIENvbW1lbnQ8L2xhYmVsPgogICAg ICAgICAgICAgICAgICAgIDxkaXYgY2xhc3M9ImNvbC1tZC02Ij4KICAgICAgICAgICAgICAgICAg ICAgICAgPHRleHRhcmVhIHJvd3M9IjYiIGNsYXNzPSJmb3JtLWNvbnRyb2wiIGlkPSJjb21tZW50 cyIgbmFtZT0iY29tbWVudHMiIHBsYWNlaG9sZGVyPSJZb3VyIHF1ZXN0aW9uIG9yIGNvbW1lbnQg aGVyZSI+PC90ZXh0YXJlYT4KICAgICAgICAgICAgICAgICAgICA8L2Rpdj4KICAgICAgICAgICAg ICAgIDwvZGl2PgogICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iZm9ybS1ncm91cCI+CiAgICAg ICAgICAgICAgICAgICAgPGRpdiBjbGFzcz0iY29sLW1kLTYiPgogICAgICAgICAgICAgICAgICAg ICAgICA8YnV0dG9uIHR5cGU9InN1Ym1pdCIgdmFsdWU9IlN1Ym1pdCIgY2xhc3M9ImJ0biBidG4t Y3VzdG9tIHB1bGwtcmlnaHQiIGlkPSJzZW5kX2J0biI+U2VuZDwvYnV0dG9uPgogICAgICAgICAg ICAgICAgICAgIDwvZGl2PgogICAgICAgICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgIDwvZm9y bT4KICAgICAgICA8L2Rpdj48IS0tIEVuZCBvZiBNb2RhbCBib2R5IC0tPgogICAgICAgIDwvZGl2 PjwhLS0gRW5kIG9mIE1vZGFsIGNvbnRlbnQgLS0+CiAgICAgICAgPC9kaXY+PCEtLSBFbmQgb2Yg TW9kYWwgZGlhbG9nIC0tPgogICAgPC9kaXY+PCEtLSBFbmQgb2YgTW9kYWwgLS0+CjwvZGl2Pjwh LS0gRW5kIG9mIENvbnRhaW5lciAtLT4KPCEtLSBqUXVlcnkgKG5lY2Vzc2FyeSBmb3IgQm9vdHN0 cmFwJ3MgSmF2YVNjcmlwdCBwbHVnaW5zKSAtLT4KPHNjcmlwdCBzcmM9Imh0dHA6Ly9jZG5qcy5j bG91ZGZsYXJlLmNvbS9hamF4L2xpYnMvanF1ZXJ5LzIuMC4zL2pxdWVyeS5taW4uanMiPjwvc2Ny aXB0Pgo8IS0tIEluY2x1ZGUgYWxsIGNvbXBpbGVkIHBsdWdpbnMgKGJlbG93KSwgb3IgaW5jbHVk ZSBpbmRpdmlkdWFsIGZpbGVzIGFzIG5lZWRlZCAtLT4KPHNjcmlwdCBzcmM9Imh0dHA6Ly9jZG5q cy5jbG91ZGZsYXJlLmNvbS9hamF4L2xpYnMvdHdpdHRlci1ib290c3RyYXAvMy4yLjAvanMvYm9v dHN0cmFwLm1pbi5qcyI+PC9zY3JpcHQ+Cgo8L2JvZHk+CjwvaHRtbD4K