I'm a bit baffled about bug 1789877. My best theory so far is that we're
inserting the element a bit deeper in the DOM and that causes us to
reflow slightly more stuff when tab-switching, but...
In any case while going through the code the status panel can be
simplified a bit now, so do that.
Differential Revision: https://phabricator.services.mozilla.com/D156876
Right now, the vertical position of the status panel is the "auto"
position, which ends up working out, but mostly by chance, and relies on
behavior that's different from the standard flexbox, see bug 1789165.
Instead of using `position: fixed` and relying on not having any
sidebars or other content to the inline-end (otherwise the [mirror] rule
would be incorrect), explicitly position it against the
.browserContainer.
Differential Revision: https://phabricator.services.mozilla.com/D156384
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
The copy guidance recommends adding an ellipsis to the end of labels for
controls that require an additional step to complete the action
specified by the label. We have some menuitems and panel buttons that
open a bookmark dialog or the edit bookmark panel that don't have an
ellipsis, so add that. Also, the form "Bookmark this x" has been changed
to "Bookmark x" in menuitems. Also, there's a "Print Selection" menuitem
that needed an ellipsis. Thanks for the review!
Differential Revision: https://phabricator.services.mozilla.com/D154320
This simplifies a bit the tabbrowser/tab switcher code, and makes it
work in all windows.
The WPT failures are due to bug 1780212.
Differential Revision: https://phabricator.services.mozilla.com/D151822
Just like it manages content, so that we stop chrome animations and such
in hidden or fully-occluded windows too. This already happened on macOS
for minimized windows via PauseCompositor, but this should be better and
more consistent.
Differential Revision: https://phabricator.services.mozilla.com/D151818
Just like it manages content, so that we stop chrome animations and such
in hidden or fully-occluded windows too. This already happened on macOS
for minimized windows via PauseCompositor, but this should be better and
more consistent.
Differential Revision: https://phabricator.services.mozilla.com/D151818
Right now we rely on the menulist to be injected by hand in all the
relevant windows. Instead create it lazily, making the select code more
standalone.
The DevTools window was missing it, for example.
Differential Revision: https://phabricator.services.mozilla.com/D149620
The tab context menu is designed to not be translated until the user
interacts with the tab strip in some way. However, the tab context menu
is now shared between the tab strip and the "all tabs" panel. So, it's
possible to open the tab context menu without interacting with the tab
strip. This results in the context menu being opened before it is
translated, so the user sees an essentially blank menu. Resolve this
by adding to the all tabs panel an extra initialization step that will
automatically translate the tab context menu.
Differential Revision: https://phabricator.services.mozilla.com/D142850
This should mostly avoid the issue where newly created pinned tabs when
restoring a session are first created in the shared web process, and
migrated into the correct process upon navigating. I also added
remoteType prediction to the undoCloseTab and duplicateTab codepaths
to avoid unnecessary process changes there as well.
Differential Revision: https://phabricator.services.mozilla.com/D141146
This should mostly avoid the issue where newly created pinned tabs when
restoring a session are first created in the shared web process, and
migrated into the correct process upon navigating. I also added
remoteType prediction to the undoCloseTab and duplicateTab codepaths
to avoid unnecessary process changes there as well.
Differential Revision: https://phabricator.services.mozilla.com/D141146
