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

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Toolbar, defect)

Description

[bull500]

Attachment: 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: http://www.engadget.com/
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 www.techcrunch.com as well and many other side that implement this form of layout

Issue listed on webcompat as well - https://webcompat.com/issues/1560

Additional Info:
Happens on both beta FF42 and Nightly FF44

Device:
Moto G 2nd Gen Lollipop 5.0.2

Comment 1

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

How do you activate Full Screen Mode?

Comment 2

[bull500]

(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

Comment 3

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

I can see this on my N5 & GS5.

Comment 4

[Brad Lassey [:blassey] (use needinfo?)]

Kats, do you have a plan for these types of scenarios?

Comment 5

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 6

[bull500]

This issue seems to happen without the full screen mode enabled as well.
Issue occurs here - http://www.popsci.com/new-horizons-spacecraft-discovers-polar-cap-pluto-and-more

Firefox 45

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Attachment: Patch

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.

Comment 8

[Matt Woodrow (:mattwoodrow)]

Comment on attachment 8685437 [details] [diff] [review]
Patch

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

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

indent

Comment 9

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/fe8c4e0c7ef0

Comment 10

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/fe8c4e0c7ef0

Comment 11

[Kartikaya Gupta (email:[e-mail])]

Attachment: Follow-up

I screwed up the other patch, the "sides" value wasn't actually getting sent across to the compositor. Whoops!

Comment 13

[Kartikaya Gupta (email:[e-mail])]

reopening to land the follow-up.

Comment 14

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/65025d08a5fb

Comment 15

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/65025d08a5fb

Comment 16

[Kevin Brosnan [Ex-Mozilla]]

[Tracking Requested - why for this release]: regression with a fix

Kats would this patch be safe to uplift?

Comment 17

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 18

[Kartikaya Gupta (email:[e-mail])]

Attachment: Rollup patch for aurora

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

Comment 19

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

bull500, would you be able to verify that this issue is fixed as expected on the latest Nightly build? Thanks.

Comment 20

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Tracked for FF44 and requesting QE team to verify the fix on Fennec builds if this issue is easy to reproduce.

Comment 21

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

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.

Comment 22

[bull500]

(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

Comment 23

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/a9889f824f98
https://hg.mozilla.org/releases/mozilla-aurora/rev/044c36c2db7f

Comment 24

[Liz Henry (:lizzard)]

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.

Comment 25

[Mira Lobontiu (Android QA)]

Hi,

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!