Horizontal and vertical scrollbars in upgrade dialog at some Windows OS zoom/scaling settings
Categories
(Firefox :: Messaging System, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr78 | --- | unaffected |
| firefox88 | --- | unaffected |
| firefox89 | + | verified |
| firefox90 | --- | verified |
People
(Reporter: aryx, Assigned: Mardak)
References
(Regression)
Details
(Keywords: regression, Whiteboard: [proton-onboarding] [priority:2b])
Attachments
(1 file)
|
43.73 KB,
image/png
|
Details |
screenshot: upgrade dialog with scroll bars
Firefox 89.0b12 and 90.0a1 20210514215821 on Windows 8.1, 1920x1080 screen resolution and 125% zoom on the OS level, task bar is on the left of the screen.
The upgrade dialog has a horizontal and a vertical scroll bar.
Bisection identifies https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=310d7fce2d0ed6c833513e20c9ad4aae1104c455&tochange=4a4264b2122a29c25536045de9b25f2749b7266f as the starting push - bug 1706279 should be the regressing change.
|
Assignee | |
Comment 1•3 years ago
|
||
Hmmmmm.... The screenshot is of the "full height" mode not the compact added in bug 1706279. Does this happen every time the dialog opens? You can force it open with:
Cc["@mozilla.org/browser/browserglue;1"].getService().wrappedJSObject._showUpgradeDialog()
(from browser console if devtools.chrome.enabled or from about:support)
I have been seeing scrollbars in rtl sometimes as part of testing bug 1710955 also non-compact mode, so I'll try to track down what's causing this.
|
Reporter | |
Updated•3 years ago
|
|
|
Assignee | |
Comment 3•3 years ago
•
|
||
Okay I was able to reproduce this on beta with 1920x1080 125%. I'm not familiar with the zoom/scaling setting, but assuming I go with the value that I set in "advanced scaling settings" on the previous session before sign out/in (instead of the 350% number showing on the main Display Settings screen??), I don't see scrollbars at 3360x2100 100%, 150%, 201% (can't set 200%??). But I do see scrollbars at 250%. Not at 300% because it switches to compact mode from bug 1706279.
Gijs, I do notice the scroll is on the <html> of the upgrade dialog, and at some zoom levels, if I temporarily set overflow: hidden from devtools then unset that style, the scrollbars don't reappear, so the scrollbars showing up are causing the scrollbars to continue showing (i.e., they're scrolling to be able to scroll what's covered up by the scrollbars). If I increase the height of the containing <browser> by 1px, the scrollbars do disappear.
Anything I should be looking at? I do use the mozSubdialogReady. I wonder if I should just increase the minHeight by 1px…
|
|
Assignee | |
Updated•3 years ago
|
|
|
Assignee | |
Comment 4•3 years ago
|
||
At 3360x2100 220%, I do see scrollbars and the upgrade dialog <html> and <body> have a box height of 593.2px. Maybe there's rounding issues, so perhaps the +1 or a ceil would fix? At this scaling, the overflow: hidden then unset makes the scrollbar go away for me.
|
|
Assignee | |
Comment 5•3 years ago
•
|
||
Aha indeed on nightly. The containing <browser> has
height:min(
calc(100vh - 0px),
var(--inner-height, 593px)
);
--inner-height: 593px;
And beta is just plain
height: 593px;
so browser box height ends up 593px while the content inside is 593.2px.
|
|
Assignee | |
Comment 6•3 years ago
•
|
||
Thanks long/int api ? :P
[getComputedStyle(temp0).height, temp0.scrollHeight]
Array [ "593.2px", 593 ]
|
|
Assignee | |
Comment 7•3 years ago
•
|
||
Looks like rounding up the height from 593.2px to 594px before resolving mozSubdialogReady did not help avoid the scrollbars. If instead I do:
documentElement.style.overflow = "hidden";
mozSubdialogReady();
requestAnimationFrame(() => documentElement.style.overflow = "");
The scrollbars do not show up even when continuing to the next upgrade dialog screens. They do appear when I change between html[dir=ltr] or rtl (either direction), and scrollbars again go away if I toggle overflow hidden/clip on then off, but users wouldn't normally be switching direction anyway…
Should I just workaround with the overflow then raf(undo)?
|
|
Assignee | |
Comment 8•3 years ago
|
||
I see the scrollbars at 3360x2100 220% when I force rtl with intl.l10n.pseudo=bidi even going back to the initial upgrade dialog landing from bug 1697222 in 89. I also see that always having a overflow-x: hidden on the body is enough to prevent this. And we have a specified width anyway, so I'm more comfortable with just having that as a persistent style than the temporary overflow/undo.
So perhaps bug 1706279 did regress it for ltr but it was always a bug for rtl for some reason.
|
|
Assignee | |
Comment 9•3 years ago
•
|
||
For my testing with win10 1809 3360x2100 220% plain en-US no bidi, it seems like this is the regression range:
2021-04-16-15-51-49 good https://hg.mozilla.org/mozilla-central/rev/a62c94365ebbc7ef63387b322827e2e7b9ecc9d0
2021-04-17-09-50-08 bad https://hg.mozilla.org/mozilla-central/rev/4f124a8d83d125b2f95fb6f9c6adc2b947dc6bfb
I would guess bug 1705292 as it seems to be sensitive to even partial px changes to the styling.
Edit: Yup, confirmed with autoland builds that it's some change from bug 1705292.
|
||
Updated•3 years ago
|
|
||
Comment 10•3 years ago
|
||
(In reply to Ed Lee :Mardak from comment #7)
Looks like rounding up the height from 593.2px to 594px before resolving mozSubdialogReady did not help avoid the scrollbars. If instead I do:
documentElement.style.overflow = "hidden"; mozSubdialogReady(); requestAnimationFrame(() => documentElement.style.overflow = "");The scrollbars do not show up even when continuing to the next upgrade dialog screens. They do appear when I change between html[dir=ltr] or rtl (either direction), and scrollbars again go away if I toggle overflow hidden/clip on then off, but users wouldn't normally be switching direction anyway…
Does the determined inner height for the dialog change with this (ie overflow + undo) workaround, vs current central? That is, does that perhaps explain the scrollbar presence/absence?
|
|
Assignee | |
Comment 11•3 years ago
|
||
Here's with manual changing overflow from console (i.e., after mozSubdialogReady):
wh = v => [v.width, v.height];
_ = e => [...wh(getComputedStyle(e)), ...wh(e.getBoundingClientRect()), e.scrollWidth, e.scrollHeight, e.clientWidth, e.clientHeight];
[_(docE), "\n", _(docE.ownerGlobal.frameElement)].join("")
587.2px,593.2px, 587.2000122070312,593.2000122070312, 604,593, 587,576
604px,593px, 604,593, 604,593, 604,593
--inner-height == 593px
docE.style.overflowX = "hidden";
604px,593.2px, 604,593.2000122070312, 604,593, 604,593
604px,593px, 604,593, 604,593, 604,593
--inner-height == 593px
And with overflow: hidden before mozSubdialogReady() then raf undo:
604px,593.2px, 604,593.2000122070312, 604,593, 604,593
604px,593px, 604,593, 604,593, 604,593
--inner-height == 593px
Both are against m-c, which has the --inner-height var. I believe the difference in client* related values in the first case are just the scrollbar visible sizes?
|
||
Updated•3 years ago
|
|
||
Updated•3 years ago
|
|
||
Updated•3 years ago
|
|
|
Assignee | |
Comment 12•3 years ago
|
||
|
|
Assignee | |
Comment 13•3 years ago
|
||
And uplifted with bug 1710955
https://hg.mozilla.org/releases/mozilla-beta/rev/819a390c26d7
|
||
Updated•3 years ago
|
|
|
Assignee | |
Updated•3 years ago
|
|
||
Updated•3 years ago
|
|
||
Comment 14•3 years ago
•
|
||
I have verified that this issue is no longer reproducible with the latest Firefox Nightly (90.0a1 Build ID - 20210525153449) and the latest Firefox Beta (89.0 Build ID - 20210524222230) installed on Windows 10 x64, Windows 8.1 x64, and Windows 7 x64. Now, I can confirm that the scrollbars are no longer displayed inside the Upgrade modal if the taskbar is in the left part of the screen and the zoom level is set to 125%.
Description
•