Bug 237851 - visualViewport.offsetTop is sometimes 0 when soft keyboard is open on web app mode
Summary: visualViewport.offsetTop is sometimes 0 when soft keyboard is open on web app...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: Safari 15
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2022-03-14 15:01 PDT by Yuwei
Modified: 2023-07-17 13:51 PDT (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yuwei 2022-03-14 15:01:28 PDT
iOS version: 15.4
iPhone: iPhone 12 Pro

---

Steps:

1. Have a website that has a text input that is fixed to the bottom of the page
2. Add the website to the home screen
3. Open the web app on the home screen
4. Open JS console and run this:
   visualViewport.addEventListener('resize',  () => console.log('viewport offsetTop, height:', visualViewport.offsetTop, visualViewport.height))
5. Tap the text input, which should bring up the soft keyboard, then tap `Done` to close it, then tap the text input again. Do it a few times and observe the JS console logs

---

Expected:

Whenever the soft keyboard is open, the log should consistently look like:

  viewport offsetTop, height: 380 - 417

---

Actual:

The log is sometimes correct, but other times I will see a 0 offsetTop, like:

  viewport offsetTop, height: 0 - 417

If I add setTimeout() to the event handler and log offsetTop with a 50ms delay, then offsetTop will be 380 even when it first reports 0 inside the event handler.

Note that I have only seen it on the web app. I haven't reproed it on mobile Safari.
Comment 1 Radar WebKit Bug Importer 2022-03-16 05:39:18 PDT
<rdar://problem/90364854>
Comment 2 ik 2023-04-02 03:09:29 PDT
Just ran into a similar issue, but in my case it's reliable for installed web apps but not in regular safari. Sadly, attempts to write a simplified testcase result in correct behavior so can't help in that regard. 

Wrapping the code in the resize listener in a 'before next paint' (double rAF) fixes it - so similar to the OP's setTimeout workaround.

Is it possible that the visualViewport resize event sometimes fires too soon or the height calculation happens too late ?