Closed Bug 1214267 Opened 4 years ago Closed 4 years ago

Top Header bar of websites tends to move/float during scrolling when Full-Screen Mode is enabled


(Firefox for Android :: Toolbar, defect)

42 Branch
Not set



Firefox 45
Tracking Status
firefox42 --- affected
firefox43 + wontfix
firefox44 + fixed
firefox45 + fixed
fennec + ---
firefox63 --- unaffected


(Reporter: bullionareboy, Assigned: kats)




(4 files)

Attached image engadget.png
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20151013030225

Steps to reproduce:

Have Full Screen Mode enabled

1. Go to:
2. Start scrolling slowly without lifting finger. 
3. Notice the header bar of the website moving away from its fixed top position.

Actual results:

The Header Bar of the website floats away from its fixed position

Expected results:

The Header Bar of the website should stay fixed on its top position even in Full Screen Mode

Happens on as well and many other side that implement this form of layout

Issue listed on webcompat as well -

Additional Info:
Happens on both beta FF42 and Nightly FF44

Moto G 2nd Gen Lollipop 5.0.2
OS: Unspecified → Android
Hardware: Unspecified → ARM
How do you activate Full Screen Mode?
Flags: needinfo?(bullionareboy)
(In reply to Michael Comella (:mcomella) from comment #1)
> How do you activate Full Screen Mode?

3-dot "Hamburger" menu > Settings > Display > Full-Screen browsing
Flags: needinfo?(bullionareboy)
I can see this on my N5 & GS5.
tracking-fennec: --- → ?
Ever confirmed: true
Kats, do you have a plan for these types of scenarios?
Flags: needinfo?(bugmail.mozilla)
A quick investigation shows that the nav element has position:fixed;top:-2px and the -2 is causing our code to not treat it as a fixed-pos element. Most likely the anchor on the fixed position layer is being misinterpreted. Assigning to myself to find a fix for this.
Assignee: nobody → bugmail.mozilla
Flags: needinfo?(bugmail.mozilla)
Component: General → Graphics, Panning and Zooming
tracking-fennec: ? → +
This issue seems to happen without the full screen mode enabled as well.
Issue occurs here -

Firefox 45
Attached patch PatchSplinter Review
This bug only affects Fennec because the dynamic toolbar allows a compositor-side viewport resizing. We want to keep fixed-pos items fixed during the async state, and to do that we need to know which side they're fixed to. We were inferring it from the anchor but that doesn't always work so this patch makes it more explicit.
Attachment #8685437 - Flags: review?(matt.woodrow)
Comment on attachment 8685437 [details] [diff] [review]

Review of attachment 8685437 [details] [diff] [review]:

::: gfx/layers/composite/AsyncCompositionManager.cpp
@@ +293,4 @@
>      translation.x += aFixedLayerMargins.left;
>    }
> + if ((sides & eSideBitsTopBottom) == eSideBitsTopBottom) {

Attachment #8685437 - Flags: review?(matt.woodrow) → review+
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 45
Attached patch Follow-upSplinter Review
I screwed up the other patch, the "sides" value wasn't actually getting sent across to the compositor. Whoops!
Attachment #8686634 - Flags: review?(matt.woodrow)
Attachment #8686634 - Flags: review?(matt.woodrow) → review+
Duplicate of this bug: 1220499
reopening to land the follow-up.
Resolution: FIXED → ---
Closed: 4 years ago4 years ago
Resolution: --- → FIXED
[Tracking Requested - why for this release]: regression with a fix

Kats would this patch be safe to uplift?
Flags: needinfo?(bugmail.mozilla)
I think it should be ok to uplift to Aurora. I think it's a little risky for beta. I'll make an uplift patch and flag it.
Flags: needinfo?(bugmail.mozilla)
Approval Request Comment
[Feature/regressing bug #]: been this way for a long time
[User impact if declined]: on some websites fixed-position items don't move smoothly while panning. Specifically this would affect fixed-pos items with negative positioning.
[Describe test coverage new/current, TreeHerder]: tested locally
[Risks and why]: Low/medium risk. This code is not as well understood since it hasn't been touched in a while. The patch itself is relatively straightforward even though it looks "large" because most of it is just propagating data around.
[String/UUID change made/needed]: none
Attachment #8689658 - Flags: approval-mozilla-aurora?
bull500, would you be able to verify that this issue is fixed as expected on the latest Nightly build? Thanks.
Flags: needinfo?(bullionareboy)
Tracked for FF44 and requesting QE team to verify the fix on Fennec builds if this issue is easy to reproduce.
Flags: qe-verify+
Comment on attachment 8689658 [details] [diff] [review]
Rollup patch for aurora

This fix has been on Nightly for 2 weeks or so now and given that this is needed to properly fix the original issue, taking it for Aurora44.
Attachment #8689658 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(In reply to Ritu Kothari (:ritu) from comment #19)
> bull500, would you be able to verify that this issue is fixed as expected on
> the latest Nightly build? Thanks.

yup! This works great on the latest Nightly build (2015-11-23) 
Thank you everyone! :D
Flags: needinfo?(bullionareboy)
Marking wontfix for 43 based on comment 17. We could have given it a try earlier, but this late in beta it doesn't seem like a good idea.
Depends on: 1236266

I was not able to reproduce the issue.

Tested with:
Browser / Version: Firefox Mobile Nightly 63.0a1 (2018-08-19)
Operating System: Oneplus Two (Android 6.0.1)

Thank you!
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.