[Webkit-unassigned] [Bug 259451] New: Mobile keyboard fixed position prevents users from accessing forms at the bottom of content in child overflow elements

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=259451

            Bug ID: 259451
           Summary: Mobile keyboard fixed position prevents users from
                    accessing forms at the bottom of content in child
                    overflow elements
           Product: WebKit
           Version: Safari 15
          Hardware: iPhone / iPad
                OS: iOS 15
            Status: NEW
          Severity: Major
          Priority: P2
         Component: New Bugs
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: jab_creations at yahoo.com

Created attachment 467100

  --> https://bugs.webkit.org/attachment.cgi?id=467100&action=review

The iPhone 6S screen unable to scroll to the bottom of the page because the keyboard is positioned over it.

#1, The Problem:
While using Safari on my iPhone 6S I noticed that I could not see the content element (#editor_rich) while using the on-screen keyboard to type. If the on-screen keyboard was visible and I scrolled down the page the browser would flip-out and ultimately return back near the top of the page.

#2, Initial Cause:
On most websites the menu scrolls upwards with the content, I don't do this. So I use html, body {overflow: none;}.

Instead I use #body {overflow;} as the primary scrolling element on pages allowing users to access the menu without having to scroll back to the top of the page. You can explore the DOM on the website, it's not the typical nightmare you'll commonly encounter.

#3, Verified Overflow:
Yes, I verified that this bug does not occur in normal scenarios where the overflow hasn't been changed though the form is still on the bottom of the page while using Safari on a mobile phone. So this bug is definitely caused because whoever programmed the keyboard did not take this scenario in to consideration.

#4, Work-Around:
On Thursday the 20th I attempted to determine how to detect this issue. There may be a way to do so however clientHeight and getBoundingClientRect() all return the same values with and without the on-screen keyboard. So the keyboard, with *days* I've allotted to try to resolve this problem, isn't, at least reasonably, able to be detected. The only thing I could determine was to blindly add padding-bottom: 230px; to the current page if it had a tag_('form').length > 0 on the push_current_id() (current page layer). This is obviously a work-around.

#5: Recommendation:
I highly recommend that the on-screen keyboard no longer use it's positioning. It blocks the bottom of the page and can not be inferred by a developer like me remotely, only if I have immediate physical access to the device. I can't literally babysit thousands of iPhone users across numerous websites because they may or may not be able to see what they're typing.

#6: Post-Report:
Since I've applied a work-around to minimize the effects of this bug I still have to implement an HTTP query as an exception. That exception will prevent my work-around from being applied so whoever verifies and works on this bug can see it because the URL disables the work-around. I will post the URL in the second post once the bug ID is generated.

I should note that there are other odd behaviors such as the "Done" button appearing in odd places.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230724/e5f80f5e/attachment.htm>