## 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

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.

Blocking and P1 based on today's epic gecko triage.

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.

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.

I just hit this bug while logging in with Persona, no less. I think this is more important than P3.

Ben, when do you expect to have a fix for this? Or is it still in the idea phase, per comment #7?

Let's try this.

Comment on attachment 686551 [details] 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.

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.

OK. What's next here?

Just waiting on platform changes being made in bug 805746, I think we have a solution!

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-.

Bug 805746 was required *only* to fix this bug, and was bb+ and just landed. wtb

This happens on the google.com homepage.

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

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.

This will prevent the address bar from hiding in (default) desktop builds, but I admit to not caring much about that right now.

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.

device: otoro build id: 20130113070202 Using www.soso.com then www.yahoo.com, and back to soso. Verified.

Comment on attachment 700687 [details] 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.

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