Closed Bug 797633 Opened 7 years ago Closed 7 years ago

[browser] Gaia work to prevent bouncing address bar bug


(Firefox OS Graveyard :: Gaia::Browser, defect, P3)

Gonk (Firefox OS)


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

B2G C3 (12dec-1jan)
blocking-basecamp -
Tracking Status
b2g18 + verified
b2g18-v1.0.1 --- affected


(Reporter: nhirata, Assigned: benfrancis)



(Whiteboard: QARegressExclude)


(2 files, 1 obsolete file)

## 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
3. go to
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 when you initially land there.  That's why I did step 3, 4, 5.
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 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: nobody → ben
Blocks: 796001
Blocking and P1 based on today's epic gecko triage.
blocking-basecamp: --- → +
Priority: -- → P1
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.
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
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.
Priority: P1 → P3
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.
Attached video 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?
Duplicate of this bug: 816388
Let's try this.
Attachment #686551 - Flags: review?(dale)
Comment on attachment 686551 [details] [review]

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)
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.
Target Milestone: --- → B2G C3 (12dec-1jan)
OK.  What's next here?
Just waiting on platform changes being made in bug 805746, I think we have a solution!
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: + → -
Bug 805746 was required *only* to fix this bug, and was bb+ and just landed.

This happens on the homepage.
blocking-basecamp: - → ?
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: ? → -
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)
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+
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 then, and back to soso.
Comment on attachment 700687 [details] [review]

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+
Issue is occurring in v101. While scrolling, the URL bar is displayed while the screen bounces. 

Unagi Build ID: 20130415070202
Gaia: c79e761bae4d92f329154c64159f4f5c8eb49c9e
Duplicate of this bug: 802345
Duplicate of this bug: 804800
Attachment mime type: text/plain → text/x-github-pull-request
You need to log in before you can comment on or make changes to this bug.