Bug 176896 - Wrong caret position for input field inside a fixed position parent on iOS 11
Summary: Wrong caret position for input field inside a fixed position parent on iOS 11
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: Other
Hardware: iPhone / iPad iOS 11
: P1 Normal
Assignee: Simon Fraser (smfr)
URL:
Keywords: InRadar
: 179927 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-09-14 04:59 PDT by daria
Modified: 2018-08-23 00:04 PDT (History)
86 users (show)

See Also:


Attachments
Screenshot of mispositioned caret (197.92 KB, image/png)
2017-09-14 04:59 PDT, daria
no flags Details
Testcase (670 bytes, text/html)
2017-10-17 16:51 PDT, Simon Fraser (smfr)
no flags Details
Ipad landscape testcase (1.10 KB, text/html)
2017-11-03 04:09 PDT, lpillonel
no flags Details
Firefix test xenforo.com/community/ On iPhone X (569.59 KB, image/png)
2017-11-08 06:41 PST, Jesse
no flags Details
Workaround #1 with js (2.87 KB, text/html)
2017-11-16 04:38 PST, Manuel Otto
no flags Details
Patch (20.50 KB, patch)
2017-12-07 18:51 PST, Simon Fraser (smfr)
thorton: review+
Details | Formatted Diff | Diff
Unexpected UI render (164.08 KB, image/jpeg)
2017-12-13 10:32 PST, Tobias
no flags Details
Incorrect caret position (235.88 KB, image/jpeg)
2017-12-13 13:02 PST, Casey Jenks
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description daria 2017-09-14 04:59:33 PDT
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.
Comment 1 Wenson Hsieh 2017-09-14 07:31:14 PDT
This is <rdar://problem/33726145>.
Comment 2 James Ravenscroft 2017-09-21 12:35:57 PDT
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.
Comment 3 johnc 2017-09-23 15:13:14 PDT
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.
Comment 4 johnc 2017-09-23 15:58:55 PDT
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.
Comment 5 Jon Lee 2017-09-25 10:50:16 PDT
<rdar://problem/33726145>
Comment 6 jasbir 2017-10-17 00:22:15 PDT
I am also facing the same issue only on Safari 11+.
Comment 7 Simon Fraser (smfr) 2017-10-17 16:51:09 PDT
Created attachment 324069 [details]
Testcase
Comment 8 Simon Fraser (smfr) 2017-10-17 17:11:35 PDT
I can reproduce with the attachment, but only with certain types of scroll after loading (on plus-sized iPhone in the simulator).
Comment 9 Simon Fraser (smfr) 2017-10-17 18:42:13 PDT
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.
Comment 10 Simon Fraser (smfr) 2017-10-17 19:59:12 PDT
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.
Comment 11 Simon Fraser (smfr) 2017-10-17 20:02:08 PDT
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.
Comment 12 Simon Fraser (smfr) 2017-10-17 20:26:35 PDT
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
Comment 13 laura.johannet 2017-10-20 13:15:46 PDT
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).
Comment 14 Manuel Otto 2017-10-31 12:41:47 PDT
It appears this bug has been fixed on iOS 11.2.
Comment 15 Simon Fraser (smfr) 2017-10-31 13:52:41 PDT
I don't think so.
Comment 16 Manuel Otto 2017-10-31 14:00:06 PDT
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).
Comment 17 lpillonel 2017-11-03 04:09:51 PDT
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
Comment 18 Chris Deeming 2017-11-06 12:03:00 PST
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
Comment 19 Anand 2017-11-06 23:30:31 PST
Hi All , 
This issue is affecting us as well and happening in Iphone Chrome and Safari.
Comment 20 Jesse 2017-11-08 06:30:31 PST
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”
Comment 21 Chris Deeming 2017-11-08 06:36:28 PST
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.
Comment 22 Jesse 2017-11-08 06:41:12 PST
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.
Comment 23 Mel Freeman 2017-11-08 19:46:48 PST
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.
Comment 24 Joshua Dykstra 2017-11-09 10:23:49 PST
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?
Comment 25 Chris R 2017-11-10 03:24:55 PST
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..
Comment 26 H Leung 2017-11-15 08:35:27 PST
Is there any ways to escalate this? It is absolutely breaking everything so how is this still not fixed by apple yet???!!!
Comment 27 H Leung 2017-11-15 08:35:45 PST
Is there any ways to escalate this? It is absolutely breaking everything so how is this still not fixed by apple yet???!!!
Comment 28 Jon Lee 2017-11-15 09:26:27 PST
We haven't forgotten about this. We are aware this is an important issue and are looking into it.
Comment 29 Jesse 2017-11-15 11:14:34 PST
Have anyone tried ios 11.2 Beta 3 with this issue?
Comment 30 Manuel Otto 2017-11-15 11:16:38 PST
@Jesse
I have. Unfortunately it's still bugged.
Comment 31 Jesse 2017-11-15 11:20:49 PST
Thanks for letting me know. This is the most frustrating bug...I even experienced it on major AAA sites like Sony Playstation.
Comment 32 H Leung 2017-11-15 19:43:35 PST
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...
Comment 33 Manuel Otto 2017-11-16 04:38:12 PST
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)
Comment 34 Simon Fraser (smfr) 2017-12-05 18:33:17 PST
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.
Comment 35 Jesse 2017-12-06 12:31:10 PST
Ok so when will there be an iOS11 fix?
Comment 36 Simon Fraser (smfr) 2017-12-07 18:51:42 PST
Created attachment 328774 [details]
Patch
Comment 37 Jesse 2017-12-08 06:48:50 PST
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.
Comment 38 Simon Fraser (smfr) 2017-12-08 07:59:04 PST
I cannot make any statements about when this will get into an iOS release.
Comment 39 Tim Horton 2017-12-08 15:11:46 PST
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.
Comment 40 Simon Fraser (smfr) 2017-12-08 16:00:53 PST
https://trac.webkit.org/r225715
Comment 41 Jesse 2017-12-11 07:06:00 PST
I just downloaded Microsoft Edge for iOS 11 and the pop-up input works perfectly from that. Go figure!
Comment 42 reelreak 2017-12-11 22:30:26 PST Comment hidden (spam)
Comment 43 eric 2017-12-12 10:01:48 PST
(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.
Comment 44 Dean Jackson 2017-12-12 10:45:25 PST
(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.
Comment 45 eric 2017-12-12 11:03:22 PST
(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.
Comment 46 Simon Fraser (smfr) 2017-12-12 11:05:22 PST
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.
Comment 47 Alexandra Potseluiko 2017-12-13 04:43:30 PST
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)
Comment 48 Tobias 2017-12-13 10:32:21 PST
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.
Comment 49 Simon Fraser (smfr) 2017-12-13 10:41:21 PST
(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.
Comment 50 Casey Jenks 2017-12-13 13:02:47 PST
Created attachment 329246 [details]
Incorrect caret position
Comment 51 Casey Jenks 2017-12-13 13:03:37 PST
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.
Comment 52 Casey Jenks 2017-12-13 13:05:08 PST
(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?
Comment 53 Chris Deeming 2017-12-13 13:07:19 PST
(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.
Comment 54 Fratilai 2017-12-18 07:11:17 PST
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!
Comment 55 Marc Bornträger 2017-12-18 08:18:18 PST
I would also appreciate very much a small notice once the bug has been fixed in iOS beta.
Comment 56 Jesse 2017-12-18 13:51:32 PST
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.
Comment 57 Chris R 2017-12-19 12:02:55 PST
Just updated to public beta 11.2.5 on iPhone SE and it still seems broke :-(
Comment 58 H Leung 2017-12-19 18:52:30 PST
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?
Comment 59 TedTheDev 2017-12-20 09:02:21 PST
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.
Comment 60 gkadillak 2017-12-20 10:53:25 PST
Any update on when this will be released? This fix is preventing users from signing up on our platform.
Comment 61 Yauheni Kastsiukevich 2017-12-27 01:38:34 PST
We have the same problem. Users can not leave comments on our website 🙁 
Still waiting for news on this bug.
Comment 62 casan.mike 2017-12-28 00:58:48 PST
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
Comment 63 David 2017-12-29 03:54:50 PST
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.
Comment 64 H Leung 2018-01-05 08:41:58 PST
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...
Comment 65 Jesse 2018-01-05 08:43:28 PST
The secrecy is becoming a liability. This is 2018. Tell us what beta build this will be added to please.
Comment 66 Alexandra Potseluiko 2018-01-05 11:32:53 PST
We are still waiting for the fix bug. Is there any news on this?
Comment 67 Simon Fraser (smfr) 2018-01-05 11:38:32 PST
I will make a note here when there is a seed build available that you can test.
Comment 68 Hans Oksendahl 2018-01-16 11:29:08 PST
We are eagerly awaiting an update on this issue.  Our team is supporting multiple products which include input fields inside fixed position elements.
Comment 69 H Leung 2018-01-23 20:00:58 PST
We are approaching February, still no news and updates? You guys know this has broken the whole web right??
Comment 70 Brent Fulgham 2018-01-23 20:58:30 PST
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.
Comment 71 James Adam 2018-01-24 13:43:12 PST
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.
Comment 72 Simon Fraser (smfr) 2018-01-24 13:50:50 PST
The fix should be included in the iOS 11.3 beta which will be available soon.
Comment 73 Manuel Otto 2018-01-24 14:21:17 PST
I can confirm, the bug appears to be finally fixed on 11.3. Thanks, Simon!
Comment 74 Casey Jenks 2018-01-28 07:41:25 PST
ABOUT DAMN TIME
Comment 75 Matt R 2018-02-09 19:09:17 PST
+1 for this fix. Thank you for giving this issue attention.
Comment 76 Henrik Wenz 2018-02-12 05:48:58 PST
We just tested it in the IOS 11.3 (public-beta-2) and can't confirm the fix!
Comment 77 Brent Fulgham 2018-02-12 10:29:46 PST
(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?
Comment 78 Simon Fraser (smfr) 2018-02-12 10:42:05 PST
I assume that was a typo, given then exclamation point.
Comment 79 Fratilai 2018-02-12 11:27:39 PST
probably so, I was able to confirm the fix on my side
Comment 80 Matt R 2018-02-12 11:29:54 PST
(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.
Comment 81 mr.jimblue 2018-02-13 18:03:57 PST
+1 for this. We really need a fix for that bug. :) thanks
Comment 82 Simon Fraser (smfr) 2018-02-15 10:24:49 PST
*** Bug 179927 has been marked as a duplicate of this bug. ***
Comment 83 Dom Christie 2018-02-16 05:11:19 PST
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
Comment 84 Jon Lee 2018-02-16 09:29:41 PST
(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.
Comment 85 fuhaiwei 2018-02-18 05:16:24 PST
Waiting to fix this BUG, so I do not have to change my program.
Comment 86 Dom Christie 2018-02-19 01:05:47 PST
(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.
Comment 87 Nati 2018-03-20 01:15:15 PDT
Hey guys,
I see the bug is resolved here but still exists on my real app.
When it will be fixed ?
Comment 88 Berkay Aydin 2018-03-22 01:38:58 PDT
I can also confirm that; it looks fixed on IOS 11.3. Thanks, Simon!
Comment 89 Pavel 2018-03-26 05:20:18 PDT
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.
Comment 90 Simon Fraser (smfr) 2018-03-26 10:47:45 PDT
(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).
Comment 91 adamle02 2018-08-23 00:04:43 PDT Comment hidden (spam)