Bug 138201 – Caret doesn't move while scrolling -webkit-overflow-scrolling: touch content on iOS

• Component: Forms
• Status: NEW

[Chris Rebert]

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.

[Chris Rebert]

Have also filed this as:
<rdar://problem/18819624>

[Chris Rebert]

Created attachment 252514 [details]
Copy of 1st JS Bin example

[Chris Rebert]

I am unable to re-test the testcase against iOS 9 since it's affected by bug 150715.

[Chris Rebert]

Updated testcase to avoid bug 150715.

[Chris Rebert]

I can't reproduce this in iOS 9.2.

[Josh Pike]

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

[Chris Rebert]

Interesting. Confirmed.

[Josh Pike]

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?

[Josh Pike]

Are there are any known workaround to this? It's driving me insane and my users are constantly complaining about it.

[Carlos]

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)

[Chris Rebert]

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.

[Carlos]

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

[Josh Pike]

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!

[Josh Pike]

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.

[Simon Fraser (smfr)]

(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?

[Josh Pike]

In Apple's bug reporter? Yes. Months ago.

[Simon Fraser (smfr)]

Can you comment with the bug number please.

[Josh Pike]

24882755

[Simon Fraser (smfr)]

(In reply to comment #18)
> 24882755

Thank you. I'll look into it.

[Josh Pike]

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.

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

I can still repro this issue in UIWebView on iOS 11.1.

[Simon Fraser (smfr)]

Does it reproduce in WKWebView?

(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

[Not Internet Explorer]

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)

[Simon Fraser (smfr)]

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.

[Simon Fraser (smfr)]

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).

[Hans]

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.

[Jon M]

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.

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.

[Chet Corcos]

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! :)

[Chet Corcos]

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)
```

[Mato]

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.

[Mato]

(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.

[Simon Fraser (smfr)]

(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?

[Piotr]

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.

any solution for this!?