Bug 176896 – Wrong caret position for input field inside a fixed position parent on iOS 11

• Component: Layout and Rendering
• Status: RESOLVED FIXED

Created attachment 320762 [details]
Screenshot of mispositioned caret

If input field is located inside a parent which has position: fixed AND page content is more than height of the screen, then when typing inside this input field the caret is mispositioned (floats somewhere below)

If page content is less than height of the screen, then the caret is positioned properly.

Please see jsbin for example: http://jsbin.com/pivahiwide/

The issue happens on Chrome and Safari browsers on mobile devices with iOS 11.

[Wenson Hsieh]

This is <rdar://problem/33726145>.

[James Ravenscroft]

I'm also seeing an issue I believe is related to this one, though it's likely an iOS-related bug:

https://codepen.io/jrwebdev/pen/aLZEMx/

When focusing on the input within the fixed positioned red box on an iPad, the keyboard appears and the red box is positioned correctly, but the browser believes that the elements within it are elsewhere, so clicking on the "Hello" button does not trigger the alert. Scrolling with the keyboard open allows the browser to recalculate the position of the elements correctly so the button can be clicked and the cursor reappears in the text input. I've tried the usual hacks to force a reflow/repaint, but they do not have any effect.

I've tested this on iOS 9, 10 and 11 and it only occurs on 11, in both Safari and Chrome. The devices I tested using iOS 11 were an iPad Air 2 and an iPad Pro.

[johnc]

I am also seeing this as well. And I can confirm what James Ravenscroft mentioned that it appears there's a disconnect between what is rendered on screen and what is the true location of the elements on the page.

Test scenario: Fixed position DIV with input elements inside. Once you focus an input field, the soft keyboard shows up and the fixed DIV also slides up a little bit. Issue occurs only when the fixed DIV slides up some number of pixels > 0. At this point the cursor appears below the text field by roughly the same number of pixels that the fixed DIV moved.

However it looks like the cursor is actually in the correct location and the real problem is that the rendered HTML/Page content has been incorrectly rendered some number of pixels higher than it should have been.

I say this based on Safari's Web Inspector. After you hit this situation where the cursor is blinking below the text field, open Web Inspector, find the input field in the Elements DOM Tree and then select it. You'll see the input field colored in the browser view and it will NOT be where it is rendered on the screen. It's actually where the cursor is blinking. In fact, if you have other widgets inside the Fixed DIV (for example other input fields or buttons, etc) you'll find that they are all found not where they are rendered on screen. They line up perfectly with where the cursor is blinking.

So it seems to be a rendering issue when a Fixed DIV is moved due to the soft keyboard showing up.

I can repro on the latest Safari and Chrome on iOS 11. Does not occur on iOS 10.

[johnc]

Also confirmed James' comment that scrolling with the keyboard open seems to get everything back in sync. I am currently working around this issue by programmatically inducing some scrolling after focusing text fields within fixed divs. Not very elegant however.

[Jon Lee]

<rdar://problem/33726145>

[jasbir]

I am also facing the same issue only on Safari 11+.

[Simon Fraser (smfr)]

Created attachment 324069 [details]
Testcase

[Simon Fraser (smfr)]

I can reproduce with the attachment, but only with certain types of scroll after loading (on plus-sized iPhone in the simulator).

[Simon Fraser (smfr)]

It seems like we're not computing a new caret rect (which happens in the web process) when the use process feeds a new layout viewport to the web process.

[Simon Fraser (smfr)]

The problem is triggered by code in FrameView::updateLayoutViewport(). If we have an m_layoutViewportOverrideRect, and m_inProgrammaticScroll is true, then we compute a new layoutViewportOverride rect. We recompute a caret rect with this new layout viewport. However, the next visible content rect update from the UI process resets the layout viewport to its old value, but doesn't trigger a caret rect update because we think nothing changed.

[Simon Fraser (smfr)]

Ironically m_inProgrammaticScroll is only true because we made it true for the duration of all layouts in r142416, and programmatic scrolls needed to compute a new layout viewport in r219668.

[Simon Fraser (smfr)]

Note to self:
* maybe it's wrong for every layout to trigger the setLayoutViewportOverrideRect() case
* probably need to tell the UI process when the web process computes a new layout viewport
* why is the web process computing a different layout viewport
* need a consistent way to invalidate the caret rect when anything changes the layout viewport

Just wanted to add in that my team is also seeing this cursor bug on IOS11 when page content height is greater than the height of the screen (minus soft keyboard height.. which is small after you do that math).

[Manuel Otto]

It appears this bug has been fixed on iOS 11.2.

[Simon Fraser (smfr)]

I don't think so.

[Manuel Otto]

Hm, okay. Were there any changes made? After double-checking I can still reproduce this bug, but only under rare circumstances. (scrolling while the input is focused).

[lpillonel]

Created attachment 325880 [details]
Ipad landscape testcase

If you click on the input, the rendering will be "displaced".
What is causing the issue here is the combination of: 
- initial-scale=0.85 in the head (instead of 1)
- position:fixed for the modal-container
- page scrolling up when the keyboard is displayed

If one condition is not met, then rendering is fine

[Chris Deeming]

Just wanted to add evidence of another reproduction case here in case it helps. This is affecting potentially thousands of users for us so we are slightly concerned at the length of time it is taking, though certainly appreciate Apple is somewhat busy right now :)

https://youtu.be/iz6464FA4EM

This is a video taken from https://xenforo.com/community

Many thanks

[Anand]

Hi All , 
This issue is affecting us as well and happening in Iphone Chrome and Safari.

[Jesse]

I use Adobe Muse and this issue is affecting me as well.

I have it working most of the time but I had to flip my image and form box. This allows the iPad to work almost 100% of the time since it’s not zooming in.

Here is the link...pop up is on test home page and a few others.

http://yrb2018test.businesscatalyst.com/index.html

When on the iPhone....this only works properly if the user doesn’t scroll too far down the page by the time the 5 second pop up appears.

The funny thing is I just downloaded Firefox on my iPhone X and it works perfectly.

The issue is clearly with Chrome and Safari.

Any help would be appreciated. I can override most things within “!inportant”

[Chris Deeming]

Definitely an issue on Firefox here. Which just further just cements it’s a WebKit / Safari / WkView issue. They all use pretty much the same engine under the hood.

[Jesse]

Created attachment 326324 [details]
Firefix test xenforo.com/community/ On iPhone X

Did you try my test site on firefox?

Your website worked perfectly on my iPhone X.

[Mel Freeman]

I'm also seeing this issue on IOS 11 Chrome and Safari. The website I'm working on is using a modal with a form that is longer than the phone screen, Bootstrap v4.

[Joshua Dykstra]

This is an issue across safari and chrome and makes input fields in modal containers nearly unusable. Can we please get an ETA on a fix?

[Chris R]

Any update from Apple on fixing this? This now makes websites that rely on modal pop ups for sales/conversions becoming near on unusable. 

Old workarounds/fixes are now no longer working in iOS 11.2 Public beta..

[H Leung]

Is there any ways to escalate this? It is absolutely breaking everything so how is this still not fixed by apple yet???!!!

[H Leung]

Is there any ways to escalate this? It is absolutely breaking everything so how is this still not fixed by apple yet???!!!

[Jon Lee]

We haven't forgotten about this. We are aware this is an important issue and are looking into it.

[Jesse]

Have anyone tried ios 11.2 Beta 3 with this issue?

[Manuel Otto]

@Jesse
I have. Unfortunately it's still bugged.

[Jesse]

Thanks for letting me know. This is the most frustrating bug...I even experienced it on major AAA sites like Sony Playstation.

[H Leung]

This issue has been reported for almost 2 months, would it be possible to get an ETA on  fix? I can imagine sites are hugely affected by this bug and can do nothing but design change...

[Manuel Otto]

Created attachment 327055 [details]
Workaround #1 with js

The only way I found to prevent this bug is by setting the scroll-position (body.scrollTop) to 0. In order to keep the input in place it's possible to modify the modal's position (style.top).

The drawbacks with this approach are:
- Unexpected change of scroll position of the document
- Impossible to scroll up while in focus once the modal has been shifted upwards (due to scrollTop being 0)

[Simon Fraser (smfr)]

There are a few things going on here.

* FrameView::updateLayoutViewport() is computing a new layout viewport rect in the web process if called at the end of a layout, when m_inProgrammaticScroll is true. This wasn't intended; the m_inProgrammaticScroll check was to detect actual programmatic scrolls.

* Normally we compute a layout viewport rect in the UI process and send it to the web process. When computed in the UI process, we normally take the keyboard into account for the visible rect (m_webPageProxy.unobscuredContentRectRespectingInputViewBounds()), but this rect isn't available in the web process, so when we compute a new layout rect there, we get a different answer.

We then compute a caret rect using layout viewport rect in the web process that doesn't match the one the UI process has, resulting in an offset caret.

[Jesse]

Ok so when will there be an iOS11 fix?

[Simon Fraser (smfr)]

Created attachment 328774 [details]
Patch

[Jesse]

Thank you Simon for the update. I am not a programer...but a front end graphic design and Adobe Muse designer so could you please let me know if these updates will be applied in the next ios11.2x beta or do I need to apply some html code to fix this issue.

[Simon Fraser (smfr)]

I cannot make any statements about when this will get into an iOS release.

[Tim Horton]

Comment on attachment 328774 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=328774&action=review

> LayoutTests/fast/visual-viewport/ios/caret-after-focus-in-fixed.html:97
> +<p>This test will time out if no stable update is received.</p>

I’m not sure this is what you meant.

[Simon Fraser (smfr)]

https://trac.webkit.org/r225715

[Jesse]

I just downloaded Microsoft Edge for iOS 11 and the pop-up input works perfectly from that. Go figure!

(In reply to Simon Fraser (smfr) from comment #38)
> I cannot make any statements about when this will get into an iOS release.

No offense Simon but get your manager here if this is the case so we can have an answer. Your team has had a major outstanding bug that broke the web for millions of people and cost developers and website millions of dollars to workaround a bug created by the wealthiest company in human history. Oh, and your team took three months to fix it.

Respectfully, we deserve better than this and our customers and your users deserve better than this.

[Dean Jackson]

(In reply to eric from comment #43)
> (In reply to Simon Fraser (smfr) from comment #38)
> > I cannot make any statements about when this will get into an iOS release.
> 
> No offense Simon but get your manager here 

I'm Simon's manager. Apple doesn't make any statements about future releases.

(In reply to Dean Jackson from comment #44)
> (In reply to eric from comment #43)
> > (In reply to Simon Fraser (smfr) from comment #38)
> > > I cannot make any statements about when this will get into an iOS release.
> > 
> > No offense Simon but get your manager here 
> 
> I'm Simon's manager. Apple doesn't make any statements about future releases.

Sorry both of you, I shouldn't have acted quite like that. I hope you can appreciate how frustrating this process has been for everyone here. This bug has been a massive headache for lots of devs and there didn't seem to be a priority to fix it. Now we don't even know when the fix will be deployed. This hasn't been a good process.

Anyways, thanks for working on this and if there's anything you can do to accelerate the deploy of this fix, I'd really appreciate it.

[Simon Fraser (smfr)]

The best way you can contribute is to test developer seeds of the OS as soon as you can, and report bugs that you find. It's much better to fix a bug before it gets shipped to the public than after.

[Alexandra Potseluiko]

In our company we faced the same problem :(
It's not easy to fix it using workaround solutions, they are not very suitable for us.

It would be great if the developers could tell us when news of a solution appears)

[Tobias]

Created attachment 329232 [details]
Unexpected UI render

We've been having the same issue with the caret positioning, we managed to partially fix this with some of the workarounds out there. However it didn't quite fix it on the iPhone X.

We are also seeing issues where the rendered UI in the fixed modals (not necessarily input fields) doesn't match the positioning of the actual DOM elements. In the screenshot the 'Continue' button is highlighted using the dev tools. You can see that it isn't aligned with the rendered UI.

It seems to be an issue when the keyboard is open and the user then scrolls.

I think it might be part of the same issue but would just like to confirm this.

[Simon Fraser (smfr)]

(In reply to Tobias from comment #48)
> Created attachment 329232 [details]
> Unexpected UI render
> 
> We've been having the same issue with the caret positioning, we managed to
> partially fix this with some of the workarounds out there. However it didn't
> quite fix it on the iPhone X.
> 
> We are also seeing issues where the rendered UI in the fixed modals (not
> necessarily input fields) doesn't match the positioning of the actual DOM
> elements. In the screenshot the 'Continue' button is highlighted using the
> dev tools. You can see that it isn't aligned with the rendered UI.
> 
> It seems to be an issue when the keyboard is open and the user then scrolls.
> 
> I think it might be part of the same issue but would just like to confirm
> this.

Yes, that should be fixed by this change.

[Casey Jenks]

Created attachment 329246 [details]
Incorrect caret position

[Casey Jenks]

I just upgraded to 11.2 to test this out, and the issue is still not fixed. I believe this ticket needs to be re-opened.

[Casey Jenks]

(In reply to Casey Jenks from comment #51)
> I just upgraded to 11.2 to test this out, and the issue is still not fixed.
> I believe this ticket needs to be re-opened.

Or has this fix not made its way out to the world yet?

[Chris Deeming]

(In reply to Casey Jenks from comment #52)
> (In reply to Casey Jenks from comment #51)
> > I just upgraded to 11.2 to test this out, and the issue is still not fixed.
> > I believe this ticket needs to be re-opened.
> 
> Or has this fix not made its way out to the world yet?

It was only fixed a few days ago. There's currently no ETA as to when it will make it into an actual iOS release.

[Fratilai]

Simon, my company is in the middle of a mobile-centric redesign of our entire site, based on Bootstrap.  This issue is keeping us from going live.  

Would it be possible once the fix makes it into an iOS beta to add a comment here?

That would allow us to get some certainty about our rollout.

Thank you!

[Marc Bornträger]

I would also appreciate very much a small notice once the bug has been fixed in iOS beta.

[Jesse]

I would like an update on a beta launch as well. This issue has caused me so much wasted time and lost wages to bill clients. 

Go download this: https://itunes.apple.com/us/app/microsoft-edge/id1288723196?mt=8

Guess what...the pop-up works on Microsoft's new edge browser on the iPhone X.

[Chris R]

Just updated to public beta 11.2.5 on iPhone SE and it still seems broke :-(

[H Leung]

No offence here and my frustration is probably shared by many others, but how is such a critical issue like this taking so long to fix and release in a company of such high standards such as Apple?

[TedTheDev]

Is there an update on this being released? This is a critical bug that hits many customers in the pocketbook, as an input form bug means sign ups are impaired on Webkit iOS.

[gkadillak]

Any update on when this will be released? This fix is preventing users from signing up on our platform.

[Yauheni Kastsiukevich]

We have the same problem. Users can not leave comments on our website 🙁 
Still waiting for news on this bug.

I added a short term solution. If it can be of any help to you, have a look at it at https://stackoverflow.com/questions/46339063/ios-11-safari-bootstrap-modal-text-area-outside-of-cursor/46866149#46866149

[David]

I can confirm that this happens on IOS 11+. The issue occurs when an input located inside a parent with position fixed is focused.

Please make this bug a priority. A lot of sites have popups (containers with position fixed) with inputs and all are affected by this.

[H Leung]

We are now into 2018... is there still no update when this fix will be released? We are all being kept in the dark here by such a breaking bug...

[Jesse]

The secrecy is becoming a liability. This is 2018. Tell us what beta build this will be added to please.

[Alexandra Potseluiko]

We are still waiting for the fix bug. Is there any news on this?

[Simon Fraser (smfr)]

I will make a note here when there is a seed build available that you can test.

[Hans Oksendahl]

We are eagerly awaiting an update on this issue.  Our team is supporting multiple products which include input fields inside fixed position elements.

[H Leung]

We are approaching February, still no news and updates? You guys know this has broken the whole web right??

[Brent Fulgham]

Simon. Can you please provide ETA. And also tell us when Sony will ship this fix? And all Linux-based smart TV updates?

Also: very important for you to tell us when Tesla will ship this fix.

[James Adam]

Bug still present in iOS 11.2.5.  Average users aren't going to believe the problem is with their iPhone.  Apple knows this, hence their apathy.

[Simon Fraser (smfr)]

The fix should be included in the iOS 11.3 beta which will be available soon.

[Manuel Otto]

I can confirm, the bug appears to be finally fixed on 11.3. Thanks, Simon!

[Casey Jenks]

ABOUT DAMN TIME

[Matt R]

+1 for this fix. Thank you for giving this issue attention.

[Henrik Wenz]

We just tested it in the IOS 11.3 (public-beta-2) and can't confirm the fix!

[Brent Fulgham]

(In reply to Henrik Wenz from comment #76)
> We just tested it in the IOS 11.3 (public-beta-2) and can't confirm the fix!

You can NOT confirm the fix? Can you please provide details?

[Simon Fraser (smfr)]

I assume that was a typo, given then exclamation point.

[Fratilai]

probably so, I was able to confirm the fix on my side

[Matt R]

(In reply to Henrik Wenz from comment #76)
> We just tested it in the IOS 11.3 (public-beta-2) and can't confirm the fix!

Henrik, it would be great if you could clarify.

+1 for this. We really need a fix for that bug. :) thanks

[Simon Fraser (smfr)]

*** Bug 179927 has been marked as a duplicate of this bug. ***

[Dom Christie]

I have a list of comments followed by a comment form. The comment form expands as the user types, so to prevent it from disappearing off the bottom of the screen, the window is scrolled to the bottom on input. The JavaScript looks something like:

```
var input = document.querySelector('.message-body')
input.addEventListener('input', update)

function update () {
  window.scrollTo(0, document.body.scrollHeight)
}
```

In Safari on iOS v9 - v11.2, when the window is scrolled to the bottom, the input disappears beneath the keyboard :/ The window is still scrollable, but it seems impossible to programmatically scroll the window to the _actual_ bottom. I have created a demo of this behaviour here: http://output.jsbin.com/memukax/50

This bug is slightly different to the issues raised here as it applies to inputs _not_ in fixed containers, however it is related as it seems to have been fixed in iOS 11.3 beta 🎉

_But_, the bug fix has caused a different issue in our native app which uses an embedded web view. It implements a similar system, but this time the comment form _is_ fixed to the bottom. As before, when the user types, the window is scrolled to the bottom. This worked fine in iOS 9 - 11.2, however, in iOS 11.3 beta, the form now scrolls beyond the _top_ of the screen and there is a lot of whitespace beneath the comment form itself.

Let me know if I need to provide any more details.

Thanks

[Jon Lee]

(In reply to Dom Christie from comment #83)
> _But_, the bug fix has caused a different issue in our native app which uses
> an embedded web view.

Dom, could you file a new bug so we can track a fix there? Thanks.

Waiting to fix this BUG, so I do not have to change my program.

[Dom Christie]

(In reply to Jon Lee from comment #84)
> (In reply to Dom Christie from comment #83)
> > _But_, the bug fix has caused a different issue in our native app which uses
> > an embedded web view.
> 
> Dom, could you file a new bug so we can track a fix there? Thanks.

I have tried to create a minimal demonstration of the issue, but have failed to do so. IIRC I think we may have patched our WebView by altering the `contentInset` when the keyboard shows, so I think the problem is on our end. I'll file a new if I find out any more.

[Nati]

Hey guys,
I see the bug is resolved here but still exists on my real app.
When it will be fixed ?

[Berkay Aydin]

I can also confirm that; it looks fixed on IOS 11.3. Thanks, Simon!

[Pavel]

I still see the bug: http://jsbin.com/nujayigone/edit?html,css,js,console
Conditions: long form with inputs inside an iframe, iframe itself is inside modal with fixed position. Though if modal is absolutely positioned, the bug is present as well.

Bug is reproduced when you scroll the form and try to fill an input. On the very first input everything is fine.

[Simon Fraser (smfr)]

(In reply to Pavel from comment #89)
> I still see the bug: http://jsbin.com/nujayigone/edit?html,css,js,console
> Conditions: long form with inputs inside an iframe, iframe itself is inside
> modal with fixed position. Though if modal is absolutely positioned, the bug
> is present as well.
> 
> Bug is reproduced when you scroll the form and try to fill an input. On the
> very first input everything is fine.

Please file a new bug on this (assuming you can reproduce in iOS 11.3).