This makes it easier to get parity between legacy and regular flex
without having to either have tons of arbitrary attribute selectors in
the xul sheet, nor adding attribute lookup hacks to the html flexbox
layout.
Also, reimplement the remaining supported flex attribute-values (0 and 1)
purely in terms of CSS rules in xul.css (regardless of whether
emulate-moz-box-with-flex is enabled).
In practice these are pretty uncommon and the style attribute does the
trick in every case I've tried.
Add a debug-only assertion to ensure we preserve behavior for now.
Add a new test with another behavior difference between flexbox
emulation and old xul layout because the old reftest now passes. Use
replaced elements, which in modern flex are treated differently.
Differential Revision: https://phabricator.services.mozilla.com/D154394
This makes it easier to get parity between legacy and regular flex
without having to either have tons of arbitrary attribute selectors in
the xul sheet, nor adding attribute lookup hacks to the html flexbox
layout.
Also, reimplement the remaining supported flex attribute-values (0 and 1)
purely in terms of CSS rules in xul.css (regardless of whether
emulate-moz-box-with-flex is enabled).
In practice these are pretty uncommon and the style attribute does the
trick in every case I've tried.
Add a debug-only assertion to ensure we preserve behavior for now.
Add a new test with another behavior difference between flexbox
emulation and old xul layout because the old reftest now passes. Use
replaced elements, which in modern flex are treated differently.
Differential Revision: https://phabricator.services.mozilla.com/D154394
Both Chrome and Edge on Windows also move the swipe-to-nav arrow icon, the
distance of move seems to be a fixed value, it doesn't depend on the browser
window size. So we also use a fixed value, 100px here.
Chrome on Mac also moves the icon, but in a slightly different way. The icon is
a semicircle shape, it never leaves the edge of the browser window even if it's
moving during swipe gestures. So we introduce a new preference named
"browser.swipe.navigation-icon-move-distance" to implement platform dependent
swipe-to-nav icon behaviors. As of now the value on platforms other than Windows
is zero so that the icon never moves on the platforms.
Depends on D152951
Differential Revision: https://phabricator.services.mozilla.com/D150433
Both Chrome and Edge on Windows also move the swipe-to-nav arrow icon, the
distance of move seems to be a fixed value, it doesn't depend on the browser
window size. So we also use a fixed value, 100px here.
Chrome on Mac also moves the icon, but in a slightly different way. The icon is
a semicircle shape, it never leaves the edge of the browser window even if it's
moving during swipe gestures. So we introduce a new preference named
"browser.swipe.navigation-icon-move-distance" to implement platform dependent
swipe-to-nav icon behaviors. As of now the value on platforms other than Windows
is zero so that the icon never moves on the platforms.
Differential Revision: https://phabricator.services.mozilla.com/D150433
The use of an exception for customizing windows stems from bug 944836.
There was always an exception for `#titlebar`, which I guess would fix the scenario in the screencast attached to the bug, but it was originally macOS-specific, and then got moved to the content browser.css (in bug 1122942) - and I removed it thinking it was superfluous given the XUL CSS for all toolbars, plus some manual testing. This commit puts it back. The xul.css instance has a titlebar selector but that doesn't actually apply to Firefox's browser window anymore, so I removed it.
Differential Revision: https://phabricator.services.mozilla.com/D142449
I came across this again when trying to address bug 1756676 and figured
I would just address this bug immediately per our previous discussion
on the bug.
Differential Revision: https://phabricator.services.mozilla.com/D139421
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
