1165587 - Hard to get the browser UI back on e.g. Google Images

Status: RESOLVED FIXED

(Firefox for iOS :: General, defect)

Description

[Mike Hommey [:glandium]]

STR:
- Open google images and do an image search
- Pan down such that the url bar disappears
- Tap an image to zoom on an image

Now, you're stuck without the possibility to get the url bar back. The only way I found is to swipe from the left to go back one page.

Comment 1

[Mike Hommey [:glandium]]

Although I haven't been able to reliably reproduce it like on google images, it happened on http://downforeveryoneorjustme.com/ as well.

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

Steph is working on a different patch that could fix this issue. He can dupe this if needed

Comment 3

[Aaron Train [:aaronmt]]

Another reproducible case

Visit http://neowin.net in landscape and just pull down a bit on the page, the address bar falls off screen and it can't be shown again until a device rotation

Comment 4

[Stephan Leroux [:sleroux]]

For http://downforeveryoneorjustme.com/, it looks like the issue was related to the text input field and the scrollView not toggling toolbars when the scrollable area is too small. I've change it so regardless of how small the scrollable area is, the toolbars will always animate.

The second issue related to http://neowin.net/ seems to be related to the scrollable div at the top of the page. The scrolling behavior is interfering with the WKWebView scrolling behaviour and causing the toolbars to disappear and not come back. I compared both Safari and Chrome and it looks like they too also have problems with the toolbars being jittery but they never disappear. I'll continue investigating and see what I can do.

Comment 5

[Stephan Leroux [:sleroux]]

So couple more notes:

1. Looks like when the user is scrolling within a overflowed div, WKWebView's scroll view says it's contentOffset is (0,0), then some negative amount (0, -n), and then (0,0). This goes back and forth if you're scrolled a bit, have the toolbars hidden, and trying moving within the div. With the panning/overflow/WKWebView gestures all at play, it seems that the scrollView is having a hard time deciding what it's contentOffset actually is. This is what seems to cause some jittery-ness as well.

2. Chrome works around this issue by locking all except one gesture. For example, if the user starts scrolling inside the div, then starts scrolling vertically, the div is locked and the user can't scroll horizontally anymore. This might be the default behavior of UIWebView as that's what Chrome is using and the behavior we're seeing with WKWebView is consistent with Safari. The downside with the locking approach (if we were able to replicate it in WKWebView) is that I've had Chrome lock scrollable divs indefinitely, breaking any scrolling on that page.

The solution I have for now is to force the toolbars to be shown in the case when we have these negative/zero cycles. This works fine since any time the offset is negative, we should be showing the toolbars anyways so if anything this additional will be the toolbars that much more robust.

Comment 7

[Stephan Leroux [:sleroux]]

Attachment: PR https://github.com/mozilla/firefox-ios/pull/559

Comment 8

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Comment on attachment 8615371 [details] [review]
PR https://github.com/mozilla/firefox-ios/pull/559

LGTM

Comment 9

[Stephan Leroux [:sleroux]]

Merged.