[Linux] Light strip at bottom of "About Firefox" dialog (in dark mode)
Categories
(Core :: Graphics, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox88 | --- | unaffected |
firefox89 | --- | unaffected |
firefox90 | --- | fixed |
People
(Reporter: dholbert, Assigned: rmader)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
Note, this is basically the same symptom as described in bug 1704383, except that the platform is different and (importantly) the regression range is different, so I'm filing it separately.
STR:
- Open the "About Nightly" dialog. (Alt+H to open "help" menu, and then choose the last option)
- Drag that dialog over a dark background (to make its edges easier to see)
ACTUAL RESULTS:
The dialog itself is entirely dark, but the very bottom of the dialog has a 1px-tall strip of a light color (white or gray).
EXPECTED RESULTS:
No such strip of light color.
This is a regression, with range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=fcf92e329cf9da4eccd899ecb89cbafa1755b6ab&tochange=3b393f95a2b43a67fdb98fbbb33737a18eeb15be
--> regression from bug 1707209.
I'm using Ubuntu 20.10 on a Dell XPS 15-inch laptop, with 200% pixel-scaling enabled in my system display settings.
(It's possible (not sure) that this is a duplicate of bug 1704383 which was simply masked on Linux until bug 1707209 landed. That's just a theory, though.)
Reporter | ||
Comment 1•4 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #0)
I'm using Ubuntu 20.10 on a Dell XPS 15-inch laptop, with 200% pixel-scaling enabled in my system display settings.
Note, I can't reproduce this issue if I switch to 100% pixel-scaling. So this seems to be specific to HiDPI-configured displays (e.g. with 200% scaling).
Reporter | ||
Comment 2•4 years ago
|
||
Assignee | ||
Comment 3•4 years ago
|
||
Hm interesting. That bug should not really have an affect if the new option is not activated, however it changed some rounding patters which were previously int
to double
. The fact that MacOS, a platform that supports fractional scaling properly, has the same issue even indicates that the changes were correct and that there's some rounding error somewhere else in the stack.
Given that we're talking about a scale of 2
, I assume there's some case were we end up rounding or ceiling a value of 0.5
, which in ints would have been floored. Will look into it.
Assignee | ||
Updated•4 years ago
|
Reporter | ||
Comment 4•4 years ago
|
||
Thanks for taking a look!
Also worth noting: regressing bug 1707209 has "[wayland]" in the summary, but the system where I'm encountering this regression is not using wayland. It looks like bug 1707209 did make some general changes to the GTK nsWindow.cpp
file, which aren't wayland-specific; presumably those are the part that caused this.
Comment 5•4 years ago
|
||
Set release status flags based on info from the regressing bug 1707209
Assignee | ||
Comment 6•4 years ago
|
||
Daniel, mind checking back with the upcoming nightly build? This might have been fixed in bug 1709319
Reporter | ||
Comment 7•4 years ago
|
||
Sure -- I just updated & rebuilt mozilla-central (to get that patch), and I can confirm that this is fixed. (For good measure, I compared against a different local build from yesterday, and I confirmed that slightly-older build did indeed show the issue.)
So: this does indeed seem to be fixed by bug 1709319. I'll resolve it as FIXED with a dependency on that bug, to represent that.
Thanks for taking a look!
Reporter | ||
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 8•3 years ago
|
||
Hello,
I’ve tried to reproduce this issue using Ubuntu 20.04(X11) on Firefox 90.0a1 (2021-04-27) but without success, I modified the scale from 100% to 200% from os settings.
Is it possible for this bug to be Wayland specific, to be reproducible only in Wayland?
Reporter | ||
Comment 9•3 years ago
•
|
||
It's not Wayland-specific -- it reproduces in Xorg for me (using Nightly 2021-04-28, in Ubuntu 21.04, at 200% pixel-scaling), as well as in Wayland.
It's possible that it's theme-specific (and hence Ubuntu-version-specific). You mentioned that you're using 20.04 -- I initially reproduced it in 20.10, and I'm now using 21.04. (I don't have a 20.04 installation handy so I don't know for sure whether it's reproducible there.)
In any case, I can confirm on my end that it's fixed in current Nightly (and I confirmed that it was fixed in the first build with bug 1709319's patch, per comment 7).
If you're having trouble reproducing and want to very that any specific builds are affected/unaffected, feel free to tag me with needinfo and I'd be happy to test them.
Comment 10•3 years ago
|
||
Hello Daniel,
I don’t have Ubuntu 20.10 and neither 21.04, can you please confirm that the issue is also fixed on Firefox 90.0b4 (https://archive.mozilla.org/pub/firefox/candidates/90.0b4-candidates/build1/)?
Reporter | ||
Comment 11•3 years ago
•
|
||
Hmm, I do see the light strip at the bottom of Firefox 90b4 "about" dialog, but I actually see it in Ubuntu's packaged Firefox 89 release build as well. See attached screenshot. Nightly is still looking good.
I'm wondering if maybe there's a strong dependency on the exact content of the about
dialog here (additional text may introduce an additional fractional CSS-pixel height, which may produce a one-display-pixel-tall unpainted strip, in HiDPI environments, I guess?)
In any case: I would classify Firefox 90 b4 as affected, but it seems 89 was just as affected, which means this artifact isn't really the same as the Nightly-specific regression that I had reported here (which was fixed).
Comment 12•3 years ago
|
||
Hello Daniel,
I’ve installed a VM with Ubuntu 21.04 and I’ve reproduced the issue you mentioned in previous comment on Firefox 90.0b5 and Firefox 89.0 , and on the latest nightly it is indeed fixed.
Should I log another bug for this?
Reporter | ||
Comment 13•3 years ago
•
|
||
That'd be great -- please do, yeah. Thanks!
Note that, despite Nightly being unaffected, this other remaining bug is almost certainly not fixed in trunk - I think it just has a strong dependency on the exact content of the dialog (which varies between nightly, beta, and release); and it seems like the Nightly about-dialog content just doesn't happen to produce a height that triggers it.
(That's my best explanation for what I observed in comment 11, at least.)
Updated•3 years ago
|
Description
•