There are a few disparate changes in this commit that combine to fix the bug.
In no particular order:
- set a min-height on windows with toolbars. This extends the minimum
content size from toolbarless windows to ones with toolbars, on the
assumption that the overhead from the toolbar and tabs is always
going to be at least 25px, even in compact mode (it's significantly
more at the moment). This is also conveniently *just* enough for
dialogs with a title, body and checkbox, at the default OS font size,
to be usable (though the bottom can still get a little cut-off).
- stop assuming there's 30px frame overhead on top of the size of the
browser in which the dialog is displayed in SubDialog.jsm. This is
perhaps true in prefs where we display a titlebar outside of the
browser, but we don't do this for content/tab/window-modal dialogs
shown in browser.xhtml so the code shouldn't assume. Without this,
when the window starts off not being tall enough to fit, we were
losing an additional 30px for no reason.
- instead of subtracting the 1em padding on the <dialog> that the
default styling provides (https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/layout/style/res/html.css#815 ) just reset it to 0 and stop subtracting it.
- remove the CSS rule for tab and window-modal dialogs that depends on
`--doc-height-px`. It is never set, because it is only set for the
`limitheight` sizeto value in SubDialog.jsm, and the only
consumer that sets that is at
https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/browser/base/content/browser.js#8988
for content dialogs.
- set the margin-top for the window-modal-dialog element from CSS
instead of from the gDialogBox code in browser.css (now without the 1em
subtraction, see above).
- expose the height of the dialog to the parent of the dialog overlay
from SubDialog.jsm as --inner-height
- use CSS to ensure the dialog is off-set to be just below chrome
when its size allows this, and otherwise move it up until it
fits. There's a code comment explaining this.
Differential Revision: https://phabricator.services.mozilla.com/D114292
There are a few disparate changes in this commit that combine to fix the bug.
In no particular order:
- set a min-height on windows with toolbars. This extends the minimum
content size from toolbarless windows to ones with toolbars, on the
assumption that the overhead from the toolbar and tabs is always
going to be at least 25px, even in compact mode (it's significantly
more at the moment). This is also conveniently *just* enough for
dialogs with a title, body and checkbox, at the default OS font size,
to be usable (though the bottom can still get a little cut-off).
- stop assuming there's 30px frame overhead on top of the size of the
browser in which the dialog is displayed in SubDialog.jsm. This is
perhaps true in prefs where we display a titlebar outside of the
browser, but we don't do this for content/tab/window-modal dialogs
shown in browser.xhtml so the code shouldn't assume. Without this,
when the window starts off not being tall enough to fit, we were
losing an additional 30px for no reason.
- instead of subtracting the 1em padding on the <dialog> that the
default styling provides (https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/layout/style/res/html.css#815 ) just reset it to 0 and stop subtracting it.
- remove the CSS rule for tab and window-modal dialogs that depends on
`--doc-height-px`. It is never set, because it is only set for the
`limitheight` sizeto value in SubDialog.jsm, and the only
consumer that sets that is at
https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/browser/base/content/browser.js#8988
for content dialogs.
- set the margin-top for the window-modal-dialog element from CSS
instead of from the gDialogBox code in browser.css (now without the 1em
subtraction, see above).
- expose the height of the dialog to the parent of the dialog overlay
from SubDialog.jsm as --inner-height
- use CSS to ensure the dialog is off-set to be just below chrome
when its size allows this, and otherwise move it up until it
fits. There's a code comment explaining this.
Differential Revision: https://phabricator.services.mozilla.com/D114292
* Replace the many-shapes icon with a new simple download icon svg and update its consumers
* New start and finish animations using svg filmstrip images
* Toolbarbutton progress "bar" is a pie-chart, using a conic-gradient and a variable updated from js
* Show toolbarbutton animations even when download panel is open
Differential Revision: https://phabricator.services.mozilla.com/D113204
Switch about:welcome and upgrade dialog to use url(icon.svg) to avoid high contrast hiding gradients. Also adjusts customize mode styling to better match proton.
Differential Revision: https://phabricator.services.mozilla.com/D113701
Switch about:welcome and upgrade dialog to use url(icon.svg) to avoid high contrast hiding gradients. Also adjusts customize mode styling to better match proton.
Differential Revision: https://phabricator.services.mozilla.com/D113701
As @jfkthame pointed out on matrix, 'ch' units are based on the
rendering of the '0' character, and thus their width in CSS 'px'
can vary for fonts that line things up to device pixels, which
can cause pretty big variations if you start multiplying with
large numbers like the dialog width. As a result, the dialog
was 30 CSS pixels narrower at 100% scaling than at 150% scaling,
which caused the wrapping.
I also noticed we forgot to update the width for checkboxes
and text in dialogs after our font-size changes in bug 1701920,
so I took the opportunity of fixing that here.
Differential Revision: https://phabricator.services.mozilla.com/D112241
If the site specifies the background-color, we also specify the color to the
HTML UA style. This fixes the msn issue in a better way.
Unstyled selects would still get dark mode.
Differential Revision: https://phabricator.services.mozilla.com/D110586
This regression was partially fixed in D106670. This sets the remaining window background properties on :root in Windows 7/8.
Differential Revision: https://phabricator.services.mozilla.com/D109806
This regression was partially fixed in D106670. This sets the remaining window background properties on :root in Windows 7/8.
Differential Revision: https://phabricator.services.mozilla.com/D109806
The page actions menu is normally hidden.
When the window is smaller than a threshold, and there's more than one action,
the single actions are hidden while the menu is shown. This allows for a nicer
overflow experience.
This patch introduces a pageActions-proton test folder where we'll move proton
tests temporarily. The head.js file is just a copy of the original one, we'll
clean it up in bug 1700582 after porting the other tests.
Differential Revision: https://phabricator.services.mozilla.com/D109606
This restyling mainly focuses on the text inputs, but also adjusts some
margins so that they apply more consistently between permission panels
and the password panel.
Differential Revision: https://phabricator.services.mozilla.com/D109105
This also fixes an issue with block margins that I noticed while developing
this patch, namely that the Profiler menu item was a few pixels too short
in addition to being offset to the right.
Differential Revision: https://phabricator.services.mozilla.com/D109453
