837476 - Jittery content when URL bar hidden/unhidden

Status: RESOLVED DUPLICATE of bug 833795

(Core :: Graphics: Layers, defect)

Description

[Andrew Overholt [:overholt]]

STR
1. Open B2G browser on your unagi
2. Go to any URL
3. Scroll down slowly

Expected:

Smooth hiding/unhiding of URL bar

Actual:

Watch content bounce around as URL bar is hidden/unhidden

See this illustrative video:  http://www.youtube.com/watch?v=bOsrO4QMN_0

Comment 1

[Lukas Blakk [:lsblakk] use ?needinfo]

Happy to consider an uplift if a low risk fix is available, to v1-next, but not a shipping blocker.

Comment 3

[Milan Sreckovic [:milan] (needinfo for best results)]

Jet, do you think this is layout or graphics?

Comment 4

[Ben Francis [:benfrancis]]

(In reply to Milan Sreckovic [:milan] from comment #3)
> Jet, do you think this is layout or graphics?

It's neither, it's the browser app responding to scroll events received from the platform.

Comment 5

[Andrew Overholt [:overholt]]

Maybe Nick or Shih-Chiang have some ideas.

Comment 6

[Josh Matthews [:jdm]]

The address bar's visibility is controlled by the browser app receiving mozbrowserasyncscroll events. The decision to hide or not is controlled by the following logic:

if the event reports a top position of < 5, show the bar unless it's already showing or in transition
else if the event reports a top position of > 50, hide the bar unless it's already hidden or in transition

That suggests that we're getting strange values from the async scrolling event, since the logic appears fairly ironclad to me.

Comment 7

[Nick Cameron [:nrc]]

I think this has come up before (btw for me it is the most annoying thing about using my b2g phone in real life, I hate it so much). It only happens when you pan by keeping your finger on the screen. If you fling it is smooth. iirc it is because when the url bar goes out of view the coords get adjusted somehow and it repositions things with the new finger position (that is, the finger is in the same place, but it has new relative coords) and so we get the jitter.

I have no idea how to fix it though, or where a fix should go.

Please someone fix this though, it is so annoying.

Comment 8

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

When the URL bar is hidden, the content iframe is resized.  We may be sending some intermediate states to the browser app.  A hack like delaying asyncscroll events for a while after resizes might be good enough for v1.0.

Comment 9

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

For the ping-pong effect of awesome bar, I observed that the top value in async scrolling event will have 50px difference after resizing the content iframe. Here is the log shows why browser app invokes hideAddressBar/showAddressBar consecutively: 

>I/GeckoDump( 1514): handleScroll: evt.detail.top=49
>I/GeckoDump( 1514): handleScroll: evt.detail.top=50
>I/GeckoDump( 1514): handleScroll: evt.detail.top=50
>I/GeckoDump( 1514): handleScroll: evt.detail.top=51
>I/GeckoDump( 1514): +handleScroll: hideAddressBar
>I/GeckoDump( 1514): handleScroll: evt.detail.top=51
>I/GeckoDump( 1514): handleScroll: evt.detail.top=51
>I/GeckoDump( 1514): handleScroll: evt.detail.top=2
>I/GeckoDump( 1514): +handleScroll: showAddressBar
>I/GeckoDump( 1514): handleScroll: evt.detail.top=50
>I/GeckoDump( 1514): handleScroll: evt.detail.top=50
>I/GeckoDump( 1514): handleScroll: evt.detail.top=50
>I/GeckoDump( 1514): handleScroll: evt.detail.top=54
>I/GeckoDump( 1514): +handleScroll: hideAddressBar
>I/GeckoDump( 1514): handleScroll: evt.detail.top=54
>I/GeckoDump( 1514): handleScroll: evt.detail.top=54
>I/GeckoDump( 1514): handleScroll: evt.detail.top=5
>I/GeckoDump( 1514): handleScroll: evt.detail.top=5
>I/GeckoDump( 1514): handleScroll: evt.detail.top=5

If we adjust the UPPER_SCROLL_THRESHOLD to 70 in browser app, we can prevent the awesome bar bouncing back and forth. It is the most harmless workaround I think for v1.0, however, I'm still looking at why the top value changed after resizing content iframe.

Comment 10

[David Flanagan [:djf]]

With schien's diagnosis above, this should be trivial to fix.  Grabbing it.

Comment 11

[David Flanagan [:djf]]

Hmm. Not entirely trivial... this may be affected by the viewport coordinates of the page being displayed.

Comment 12

[David Flanagan [:djf]]

Attachment: link to patch on github

This increases the difference between the two scroll thresholds to be larger than the height of the address bar, and adds code in the scroll handler to convert viewport CSS pixels to the device pixels that the threshold is measured in.

It gets rid of the address bar flickering that could happen with slow scrolling.

It still seems somewhat suboptimal in that when the address bar is shown it obscures content that was at the top of the screen. But I can't figure out a way to also fix that in this patch.

Comment 13

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

This is a platform problem and is a duplicate of bug 833795.

Comment 14

[David Flanagan [:djf]]

Ben,

This is marked resolved, but I would still appreciate your review of my patch. I'm not convinced that the patch attached to  bug 833795 is general enough to fix the underlying issue. I think it would be better to workaround with a gaia fix like this one, and wait for a general-purpose fix in gecko.

Comment 15

[Ben Francis [:benfrancis]]

David,

Sorry for the delay in my response. It looks like bug 833795 now has a more general fix, though it was backed out. If that lands, I assume we no longer need this workaround in Gaia?

Comment 16

[David Flanagan [:djf]]

Comment on attachment 717237 [details]
link to patch on github

Cancelling the review request. I agree that the more general fix in the other bug would be better.  Let's keep this in mind as a workaround if we can't land that other one, though.