Baseline profile: https://share.firefox.dev/3p5PgDn (jank)
Profile with just setting pinned tab position to absolute: https://share.firefox.dev/30jKR5p (jank)
Profile with just moving relative positioning to CSS: https://share.firefox.dev/3p6c5a7 (jank)
Profile with this patch: https://share.firefox.dev/3FRLmnK (no jank)
Markus said setting abspos pinned tabs would be safe as long as there were no relative-positioned ancestors in the tab overflow scrollbox. The only notable ancestor of a pinned tab is the tab arrowscrollbox itself, so there aren't any surprise ancestors here. Manual testing indicates things work fine.
I also confirmed that this patch fixes bug 1725151.
Differential Revision: https://phabricator.services.mozilla.com/D121403
I've tested this (both with and without titlebar) in Linux, Win10,
Win11, Win7 and macOS.
* On macOS behavior doesn't change at all (since on fullscreen we didn't
show the buttons to begin with).
* Linux now shows "native" buttons on fullscreen (which is also an
improvement).
* On Windows 10/11 the sizing of the buttons is now the same when
fullscreen vs. not (which is an improvement).
* On Windows 7 we now use regular native-looking buttons (like on
windows 10) instead of the custom windowControls.png. That could be
considered a slight regression I guess, but is consistent with win10.
Differential Revision: https://phabricator.services.mozilla.com/D128196
Replace almost all MR1 content with MR2 start, colorway and thank you screens. Reuse confetti from about:welcome. Add variant selection with transitions. Update triggering to show for 94 but not for windows 7.
Differential Revision: https://phabricator.services.mozilla.com/D127252
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
