We need to be displayed when cloning into a same-process frame, so that
the preview code hooks up to the view tree correctly and the frame is
correctly painted.
This works for out-of-process frames, but mostly by chance.
Fortify the printPreview() API code to gracefully handle that case, and
remove the sessionrestore special-case which is not really special.
Differential Revision: https://phabricator.services.mozilla.com/D119980
This patch moves code that sets the background of the browser toolbars into
one place. It also removes some non-Proton Windows-only code rather than
updating it for this.
Differential Revision: https://phabricator.services.mozilla.com/D118658
This is the only usage of viewport units in the whole browser window and
we could live without it trivially. It avoids otherwise-unnecessary
style invalidation.
In the cloned bug I've improved the style system so that we do a lot
less work, but we still need to do a full DOM walk.
Instead let's use percentages, which only need re-layout, not restyle
(viewport units compute to a pixel value, percentages compute to
themselves).
Differential Revision: https://phabricator.services.mozilla.com/D118879
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
