Jittery content when URL bar hidden/unhidden

RESOLVED DUPLICATE of bug 833795

Status

()

Core
Graphics: Layers
RESOLVED DUPLICATE of bug 833795
5 years ago
5 years ago

People

(Reporter: overholt, Assigned: djf)

Tracking

unspecified
ARM
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(blocking-b2g:-, b2g18+)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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
Happy to consider an uplift if a low risk fix is available, to v1-next, but not a shipping blocker.
blocking-b2g: tef? → -
tracking-b2g18: --- → +
(Reporter)

Updated

5 years ago
Duplicate of this bug: 843486
Blocks: 837218
Jet, do you think this is layout or graphics?
Flags: needinfo?(bugs)
(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.
(Reporter)

Comment 5

5 years ago
Maybe Nick or Shih-Chiang have some ideas.

Comment 6

5 years ago
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

5 years ago
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.
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.
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.
(Assignee)

Comment 10

5 years ago
With schien's diagnosis above, this should be trivial to fix.  Grabbing it.
Assignee: nobody → dflanagan
(Assignee)

Comment 11

5 years ago
Hmm. Not entirely trivial... this may be affected by the viewport coordinates of the page being displayed.
(Assignee)

Comment 12

5 years ago
Created attachment 717237 [details]
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.
Attachment #717237 - Flags: review?(bfrancis)
This is a platform problem and is a duplicate of bug 833795.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 833795
(Assignee)

Comment 14

5 years ago
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.
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?
(Assignee)

Comment 16

5 years ago
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.
Attachment #717237 - Flags: review?(bfrancis)

Updated

5 years ago
Flags: needinfo?(bugs)
Duplicate of this bug: 843745
You need to log in before you can comment on or make changes to this bug.