Firefox for Android (with dark theme) shows a dark dynamic-toolbar-sized area at the bottom of the screen, when scrolling pages that use `mix-blend-mode`
Categories
(Core :: Panning and Zooming, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox115 | --- | fixed |
People
(Reporter: emilio, Assigned: hiro)
Details
Attachments
(4 files)
From github: https://github.com/mozilla-mobile/fenix/issues/24625.
Steps to reproduce
- Go to https://gankra.github.io/blah/tower-of-weakenings/ (but I've seen it in other pages recently)
- Scroll down.
- For a bit, after the address bar disappears, you see a black space.
This doesn't happen in other pages like GitHub, and I have only noticed recently.
Expected behaviour
The address bar shows and hides smoothly.
Actual behaviour
It doesn't
Device name
OnePlus 9
Android version
Android 12
Firefox release type
Firefox Nightly
Firefox version
100.0a1 (Build #2015872779), 70d7e8fc2+ AC: 100.0.20220404143034, bb1ef6830e GV: 100.0a1-20220404093932 AS: 91.1.1
Device logs
No response
Additional information
Change performed by the Move to Bugzilla add-on.
|
||
Comment 1•2 years ago
|
||
|
|
||
Updated•2 years ago
|
|
|
||
Comment 2•2 years ago
|
||
As shown in the attached testcase, this seems to just require a combination of:
- dark Firefox theme
mix-blend-mode: darkenon some element- mobile-friendly
<meta name="viewport">tab
Interestingly, this bug also reproduces if you move the Firefox toolbar to the top of the screen (Settings|Customize|Toolbar: Top), though the unexpected dark area is still at the bottom of the screen.
|
|
||
Comment 3•2 years ago
|
||
Also, this only reproduces if the page has a fully-transparent background.
So e.g. it does reproduce with this added to the testcase (fully-transparent red):
<html style="background: rgba(255,0,0,0.0)">
...but it doesn't reproduce if I change the alpha component to 0.01 (making it nearly-but-not-quite transparent red)
<html style="background: rgba(255,0,0,0.01)">
|
|
||
Comment 4•2 years ago
|
||
So this feels like it has to do with determining the appropriate clipping area, and failing to update it when the dynamic toolbar goes out of view.
CC'ing hiro since I know he's been looking at some dynamic-toolbar-related stuff, and CC'ing miko due to the possible connection to web painting.
|
|
||
Comment 5•2 years ago
•
|
||
Two additional notes:
(1) The dark bar at the bottom is actually semi-transparent, though you can't tell in my attached testcase since I don't have any visible content that traverses it. But you can see this at the original site.
(2) Regarding mix-blend-mode: darken -- "darken" is just an example value that triggers the bug, but really, it looks like any non-default value will trigger the same bug in this testcase. (In addition to darken, I tested lighten, hue, and saturation in my own copy of the attached testcase, and they all trigger exactly the same results with the dark bar at the bottom of the screen.)
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
Assignee | |
Comment 6•2 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #4)
So this feels like it has to do with determining the appropriate clipping area, and failing to update it when the dynamic toolbar goes out of view.
CC'ing hiro since I know he's been looking at some dynamic-toolbar-related stuff, and CC'ing miko due to the possible connection to web painting.
We do expand the clip area here, maybe there's another place we need to do the same thing?
|
||
Updated•2 years ago
|
|
|
Assignee | |
Comment 7•1 year ago
|
||
Both this test case and the test case Daniel posted in comment 1 have the same underlying case.
here in PresShell::AddCanvasBackgroundColorItem. We need to expand the Bounds rect to include the dynamic toolbar area.
I tried to write a JUnit test to test the Daniel's test case, mix-blend-mode case, but I couldn't find ways to set the dark mode in JUnit (even on GeckoView example). So I am going to add just the Thomas' case here.
|
|
Assignee | |
Comment 8•1 year ago
|
||
|
|
Assignee | |
Comment 9•1 year ago
|
||
Timothy, here's another one waiting on reviewing. Thanks!
|
|
||
Comment 10•1 year ago
|
||
For posterity / convenience, here's a screencast of what this bug looks like (with my attached 'testcase 1' on a Pixel 6a with current Firefox Nightly 115.0a1)
|
||
Comment 12•1 year ago
|
||
Pushed by hikezoe.birchill@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/27a022ccd011 Expand nsDisplaySolidColor's bounds including the dynamic toolbar area. r=botond,tnikkel,geckoview-reviewers,owlish
|
||
Comment 13•1 year ago
|
||
| bugherder | ||
Description
•