[browser] Gaia work to prevent bouncing address bar bug

VERIFIED FIXED in B2G C3 (12dec-1jan)

Status

Firefox OS
Gaia::Browser
P3
normal
VERIFIED FIXED
6 years ago
4 years ago

People

(Reporter: nhirata, Assigned: benfrancis)

Tracking

(Blocks: 1 bug)

unspecified
B2G C3 (12dec-1jan)
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-basecamp:-, b2g18+ verified, b2g18-v1.0.1 affected)

Details

(Whiteboard: QARegressExclude)

Attachments

(2 attachments, 1 obsolete attachment)

## Environment :
Otoro phone, build 2012-10-03 us
Taken from default.xml in b2g-distro: 
* "platform_build" revision= 795261940c8b11fb7dddd7a8e9dd8561fdc4fb64
* "gaia" revision= a3339652136fde9e5207e1bc1263a410c84f55fc 
* "releases-mozilla-central" revision= aecce9686d0b0e6ec25bb31e837eadace251a951
* "gonk-misc" revision= 202d2c62443c098b125e5d9d7b42226d98230e44
  
## Repro :
1. launch browser app
2. go to http://m.soso.com
3. go to http://www.yahoo.com
4. hit the back button
5. scroll down a little bit

## Expected :
1. the URL bar will hide

## Actual :
1. the page height is just enough so that the url bar keeps bouncing up and down

## Note :
1. for some reason you can't scroll down on m.soso.com when you initially land there.  That's why I did step 3, 4, 5.
2. http://www.youtube.com/watch?v=nVTRu-Fqk7c&feature=youtube_gdata_player
(Assignee)

Comment 1

6 years ago
That's a fun bug :)

I can't actually reproduce this at the moment because for some reason in my build from yesterday the browser is mis-reporting the viewport size or something similar, resulting in me getting the full versions of web sites instead of the mobile ones and causing a page of width and height 100% to scroll downwards and sidewards a long way. I'll try a new build.

However, I can hazard a guess at what's happening here and it's a side effect of the heuristics we use to show/hide the address bar based on scroll position thresholds.

Although I haven't been able to achieve the bouncing up and down effect you show in the video, I have a test case at http://people.mozilla.org/~bfrancis/test2.html which will bounce back up slightly if you scroll down, so you can never quite scroll to the last 5 pixels of the page. This will happen for any page with content at a height of exactly between 416-419 pixels.

I think that reducing the "LOWER_SCROLL_THRESHOLD" from 5px to 1px will probably reduce or completely prevent this effect, but it may have other side effects. I don't want to apply a patch until I can consistently re-produce and test this on the device.
(Assignee)

Updated

6 years ago
Assignee: nobody → ben

Updated

5 years ago
Blocks: 796001
Blocking and P1 based on today's epic gecko triage.
blocking-basecamp: --- → +
Priority: -- → P1
(Assignee)

Comment 3

5 years ago
Chris, should we dupe this one with bug 796001 or the other way around? You seem to be indicating in 796001 that this can be fixed on the platform side whereas this bug is attempting to solve it on the Gaia side. Which do you think it should be?
It doesn't matter to me which way we dup.  The solution to this has to cross both gecko and gaia.
(Assignee)

Comment 5

5 years ago
OK, let's keep both open, this one can track the Gaia side.
Summary: [browser] if the page is just the right height, the url bar will keep bouncing up and down after scrolling a little bit. → [browser] Gaia work to prevent bouncing address bar bug
(Assignee)

Comment 6

5 years ago
Chris, is there any action I can take on this bug right now on the Gaia side or is it blocked by a platform bug?
We need a tweak to the UX here that meets these criteria
 - show/hide URL bar causes apzc to scroll, which causes url bar to hide/show, which causes ...
 - page content isn't permanently clipped; can always be scrolled to
 - there's a reliable way to show the URL bar at any time

I haven't time to sit down and gives this the think it deserves, but I know you and gal have done some brainstorming.  We just needs ideas at this point.

Updated

5 years ago
Priority: P1 → P3
(Assignee)

Updated

5 years ago
Duplicate of this bug: 796001
I just hit this bug while logging in with Persona, no less. I think this is more important than P3.
Created attachment 685715 [details]
Video of the bug
Ben, when do you expect to have a fix for this? Or is it still in the idea phase, per comment #7?
(Assignee)

Updated

5 years ago
Duplicate of this bug: 816388
(Assignee)

Comment 13

5 years ago
Created attachment 686551 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/6712

Let's try this.
Attachment #686551 - Flags: review?(dale)
(Assignee)

Comment 14

5 years ago
Comment on attachment 686551 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/6712

Hmph. That was slightly wishful thinking, there is no bottom property in the scroll event, only top.
Attachment #686551 - Attachment is obsolete: true
Attachment #686551 - Flags: review?(dale)
(Assignee)

Comment 15

5 years ago
I think to fix this in the browser app we need to know either the distance between the bottom of the iframe and the bottom of the content, or at least the total height of the content so we can work out how much scroll is available.

Alternatively we could implement some kind of de-bouncing (literally) hack to prevent the address bar transition happening more than once within a certain period of time. That might lead to slightly unpredictable behaviour and make the problem reported in bug 805746 worse, because the address bar could temporarily get stuck off the screen as a side effect.

Updated

5 years ago
Target Milestone: --- → B2G C3 (12dec-1jan)
OK.  What's next here?
(Assignee)

Comment 17

5 years ago
Just waiting on platform changes being made in bug 805746, I think we have a solution!
(Assignee)

Updated

5 years ago
Depends on: 805746
The URL bouncing in the persona log page is the interaction between the browser app and forms.js. It happens as a result of the following events:

1. Open the browser app with full size, URL bar visible.
2. Focus on the input field. The virtual keyboard is shown.
3. The browser app shrinks its dimensions and the input field is out of the viewport.
4. forms.js receives resize event and scrolls the input field up into view.
5. Browser hides the URL bar and the content is resized. The input field is pulled up.
6. forms.js receives resize event and scrolls the input down.
7. Browser shows the URL bar and the content is resized. The input field pulled down and becomes out of the viewport.
8. Go to step 4. Here comes the perpetual motion machine.

Browser may need to differentiate scroll events from real human and from within the device to debounce the URL bar. Maybe we shouldn't hide the URL bar because of virtual keyboard shown to cut the loop from the beginning.
Driver retriage: Very narrow circumstances, difficult to reproduce. Will take a patch if available after all P1 bugs are fixed. Blocking-.
blocking-basecamp: + → -

Updated

5 years ago
tracking-b2g18: --- → +
Bug 805746 was required *only* to fix this bug, and was bb+ and just landed.

wtb
This happens on the google.com homepage.
(Assignee)

Updated

5 years ago
blocking-basecamp: - → ?
(Assignee)

Updated

5 years ago
Duplicate of this bug: 821485
Triage: BB-, as retriage. would not block ship due to this bug but if patch is available and safe to check in. may take a patch
blocking-basecamp: ? → -
Duplicate of this bug: 827731
Depends on: 828969
(Assignee)

Comment 25

5 years ago
Created attachment 700687 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/7529

NOTE: If blocking-basecamp+ is set, just land it for now.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): n/a
User impact if declined: Unreliable scrolling address bar off the screen and getting into an unrecoverable state + problems with infinite bouncing up and down of address bar
Testing completed: manual testing of scrolling address bar on/off screen with usually problematic web sites
Risk to taking this patch (and alternatives if risky): Regressions caused by the new asyncscroll event, but this has already been tested & fixed.
Attachment #700687 - Flags: review?(dale)
Attachment #700687 - Flags: approval-gaia-master?(21)

Updated

5 years ago
Blocks: 829220
This will prevent the address bar from hiding in (default) desktop builds, but I admit to not caring much about that right now.
Attachment #700687 - Flags: review?(dale) → review+

Comment 28

5 years ago
Verified fixed on Unagi build 201301120702022.
Note: Did not use soso site since Unagi browser did not load that site. Used Vivo then Yahoo, then went back to Vivo. Could not repro the issue as shown in the You Tube video.

Still needs to be verified fixed on Otoro.
Whiteboard: QARegressExclude
device: otoro
build id: 20130113070202

Using www.soso.com then www.yahoo.com, and back to soso.
Verified.
Status: RESOLVED → VERIFIED
Comment on attachment 700687 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/7529

Sounds like I forgot to add a+ when I merged it. Let' s do a post-mortem a+ then.
Attachment #700687 - Flags: approval-gaia-master?(21) → approval-gaia-master+
status-b2g18: --- → verified

Comment 31

5 years ago
Issue is occurring in v101. While scrolling, the URL bar is displayed while the screen bounces. 

Unagi Build ID: 20130415070202
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/2b44e2c40cc1
Gaia: c79e761bae4d92f329154c64159f4f5c8eb49c9e
status-b2g18-v1.0.1: --- → affected
(Assignee)

Updated

5 years ago
Duplicate of this bug: 802345
(Assignee)

Updated

5 years ago
Duplicate of this bug: 804800
Attachment mime type: text/plain text/plain → text/x-github-pull-request text/x-github-pull-request
You need to log in before you can comment on or make changes to this bug.