[Android] Top-aligned content is 1px away from top of the screen, when scrolling upwards at e.g. theregister.com (with top:0 and position:sticky or fixed)
Categories
(GeckoView :: General, defect, P3)
Tracking
(Webcompat Priority:P3, firefox-esr91 wontfix, firefox99 wontfix, firefox100 wontfix, firefox101 fixed)
People
(Reporter: dholbert, Assigned: hiro)
References
(Regressed 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(5 files)
STR:
- Visit https://www.theregister.com/ in Fenix (Firefox for Android), or GeckoView Example App
- Scroll down the page a bit.
- Scroll back up
ACTUAL RESULTS:
When you're scrolling up, the header-bar shifts slightly such that a 1px-tall-stripe of the page's white background is visible above it.
EXPECTED RESULTS:
No such white stripe.
I'm testing on a Google Pixel 4a device.
With mozregression -n gve
, I get this regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ae315341bc721084298fd39f6669bc47456a0fc5&tochange=83bf4fd3b1fbca9dcbe23de9d1a1503eed62569a
In that range, I would bet Bug 1500644 ("Make geckoview_example's toolbar behave like Focus's dynamic toolbar") is the relevant commit that caused the regression, though of course that commit was GeckoView-example-app specific; so that's perhaps just an indication that we have a separate preexisting bug that became reproducible in GeckoView-example-app starting with that that commit.
hiro, when you get a chance: do you know what might be going on here and if we already have a bug on this issue?
Reporter | ||
Updated•3 years ago
|
Reporter | ||
Comment 1•3 years ago
|
||
Reporter | ||
Updated•3 years ago
|
Reporter | ||
Comment 2•3 years ago
|
||
Assignee | ||
Comment 3•3 years ago
|
||
I thought this was fixed by https://github.com/mozilla-mobile/android-components/issues/10668, if the issue can be reproducible on Fenix, we'd probably need to use float for setVerticalClippling.
(Note that I don't see any 1 pixel gaps on my Pixel 3)
Assignee | ||
Comment 4•3 years ago
|
||
CCing Petru, he might be able to see the issue.
Reporter | ||
Comment 5•3 years ago
•
|
||
Thanks!
Also notable, I can reproduce this on https://m.facebook.com as well (where I am logged in). If I load that page, I don't initially see the 1px stripe at the top, but if I scroll upwards, the 1px white stripe scrolls into view.
I also can reproduce it one these no-login-required Facebook pages, on my Pixel 4a:
https://about.facebook.com/
https://facebook.com/business/help
...though on these ones, I have to scroll downwards first, and then scroll up, in order to see the 1px stripe.
Assignee | ||
Comment 6•3 years ago
|
||
I am supposing it depends on the device resolution. Anyway to fix this 1px gap completely we just need to change all relevant stuff of setVerticalClippling (and setDynamicToolbarMaxHeight), it should be straight forward.
Reporter | ||
Comment 7•3 years ago
|
||
Also note, you need to be sure you've got a dark theme (in the Android settings, or in the Fenix settings) to really see this issue. Android Settings | Display | Dark theme --> on
or: Firefox Settings | Customize | Theme --> Dark
Otherwise, your Android OS top-bar may have a white background; and in that case, this bug's 1px strip at the top of the viewport will just blend into that similarly-colored top bar, and you can't really notice it.
Reporter | ||
Comment 8•3 years ago
•
|
||
I can reproduce this on a Pixel 3 using BrowserStack, with a dark theme in Fenix.
(I visited https://facebook.com/business/help , scrolled down the page a bit, and then scrolled back to the top, per comment 5.)
hiro, can you reproduce on your Pixel 3 if you activate Fenix's dark theme?
Assignee | ||
Comment 9•3 years ago
|
||
Oh yeah, yes. I can see it on my pixel 3 once after I set Fenix's theme to "Dark". That's surprising, the preference was originally "Follow device theme" and my device setting is "Dark". And once after I am able to reproduce the issue, the issue still is able to be seen with "Follow device theme".
Comment 10•3 years ago
|
||
The general issue was also investigated here - https://bugzilla.mozilla.org/show_bug.cgi?id=1648079
Comment 11•3 years ago
•
|
||
(In reply to Hiroyuki Ikezoe (:hiro) from comment #6)
I am supposing it depends on the device resolution. Anyway to fix this 1px gap completely we just need to change all relevant stuff of setVerticalClippling (and setDynamicToolbarMaxHeight), it should be straight forward.
Hey Hiro, could you expand on this? It's not clear to me what needs to be done here.
Assignee | ||
Comment 12•3 years ago
•
|
||
What I meant is that changing this setVerticalClipping's argument to float (it ends up changing all relevant arguments and member variable to float altogether).
That said, I am less sure it will fix this case, if this case is same as bug 1648079, it won't fix this issue.
Reporter | ||
Comment 13•3 years ago
|
||
Turns out this is extremely-easy to trigger -- here's a reduced testcase, with a red background on the body and an element that should cover up that background fully (but does not).
STR:
- Load this testcase.
- Scroll down the page.
- Scroll back up to the top.
ACTUAL RESULTS:
There's a line of red pixels at the top of the viewport.
This reproduces on my device regardless of theme (in light or dark mode), since you can clearly see the line of red pixels regardless of whether your phone's top-toolbar is light or dark.
Updated•3 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 15•2 years ago
|
||
Note that using float for the APIs would solve this issue basically, but as far as I can tell it will not completely fix the gap since the APIs are async so that there remains a gap between rendering the toolbar and rendering the contents.
Comment 16•2 years ago
|
||
Regarding the testcases (I can reproduce also) I see that just a bit of zoom will have the issue not reproduce anymore.
Is this expected?
Assignee | ||
Comment 17•2 years ago
|
||
Assignee | ||
Comment 18•2 years ago
|
||
I was totally wrong. The APIs are not relevant with the 1px gap at all. The gap is coming from this applying NSCoordSaturatingAdd
to CSSSize in ExpandHeightForDynamicToolbarImpl.
I uploaded the fix, but still I need to figure out a way to write a test.
Updated•2 years ago
|
Comment 19•2 years ago
|
||
Pushed by hikezoe.birchill@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/11fa3e17cc1a Use NSCoordSaturatingAdd only for nsSize. r=botond
Comment 20•2 years ago
|
||
bugherder |
Comment 21•2 years ago
|
||
Setting status-firefox100=wontfix. If this bug has been around for a while and is just a visual problem that doesn't affect use of the site, then we probably don't need to uplift the fix to Beta 100.
Updated•2 years ago
|
Updated•2 years ago
|
Description
•