After the previous patch, we don't jank all remote tabs when resizing
the browser, so this can go. This should also make general window
resizing faster.
Differential Revision: https://phabricator.services.mozilla.com/D221996
Do it at the same time as UpdateRemoteFrameEffects() (so, intersection
observer timing). Otherwise we can see flickering sometimes from the
resize with the previous patch (and this should be less work, when we
resize).
Non-remote frames need to synchronously communicate their resizes
(because JS could access the frame), but that's not an issue for
remote frames.
This should also more reliably prevent issues like bug 1910887 or like
bug 1764655, and paves the way for fixing bug 1750189 (which stalled) in
a similar fashion.
I tested this in a build with a couple hundred tabs open and it doesn't
measurably show up. I think we should consider not communicating resizes
to background tabs / hidden remote iframes, at least for top levels.
Differential Revision: https://phabricator.services.mozilla.com/D221405
After the previous patch, we don't jank all remote tabs when resizing
the browser, so this can go. This should also make general window
resizing faster.
Differential Revision: https://phabricator.services.mozilla.com/D221996
Do it at the same time as UpdateRemoteFrameEffects() (so, intersection
observer timing). Otherwise we can see flickering sometimes from the
resize with the previous patch (and this should be less work, when we
resize).
Non-remote frames need to synchronously communicate their resizes
(because JS could access the frame), but that's not an issue for
remote frames.
This should also more reliably prevent issues like bug 1910887 or like
bug 1764655, and paves the way for fixing bug 1750189 (which stalled) in
a similar fashion.
I tested this in a build with a couple hundred tabs open and it doesn't
measurably show up. I think we should consider not communicating resizes
to background tabs / hidden remote iframes, at least for top levels.
Differential Revision: https://phabricator.services.mozilla.com/D221405
Among other things, the postActions method in AsyncTabSwitcher attempts to do update
"auxiliary state" once the primary state (the various STATE_ flags in particular)
have been set.
Part of its job then is to loop over the current set of tabs and determine how
many we're still waiting on to do something asynchronous (like complete loading
or complete unloading).
We have a condition that is meant to skip counting any backgrounded that should
not be set to STATE_UNLOADING because they're either being used for print preview or
Picture-in-Picture (which requires that their DocShells stay active). However,
this condition didn't take into account the possibility that such a tab is
still in the STATE_LOADING state - meaning that we're still waiting for it
to finish being composited. This meant that in certain conditions, we'd
erroneously conclude that there weren't any more tabs to wait for, and
we'd "finish", preventing the STATE_LOADING tab from ever exiting the
"pendingpaint" condition.
This patch makes it so that we only skip counting those tabs if they're in the
STATE_LOADED state.
Differential Revision: https://phabricator.services.mozilla.com/D221869
* Remove condition in tabs.js that prohibited overflow attribute being added for vertical orientation
* Remove redundant overflow-y:auto for #tabbrowser-arrowscrollbox and set a min-height for vertical tabs
Differential Revision: https://phabricator.services.mozilla.com/D221133
This patch introduces `browser.tabs.insertAfterCurrentExceptPinned`.
Setting it to `true` open links from pinned tabs at the end of the tabbar.
Differential Revision: https://phabricator.services.mozilla.com/D69489
This solves two problems. First we must make the tabbrowser-tabs instance
fill the remaining space in the sidebar while at the moment it is constrained
to the height of the tabs. Then we allow the double click event to be
handled when vertical tabs and tabs in titlebar are enabled.
Differential Revision: https://phabricator.services.mozilla.com/D220269
This is a test issue only. We now fire the overflow event later, not off
arbitrary flushes, so we gotta wait for it before trying to click the
new tab button, which might not be visible yet otherwise.
While at it, wait for the opened tabs too, which was done manually on
the caller.
Differential Revision: https://phabricator.services.mozilla.com/D220416
I first tried to fix the disabled property, but this turned into a rabbit hole that seems a bit too risky at this stage. With some luck, this may be the only place accessing these buttons' disabled property. Medium-term we still need to fix the property, ideally by making the disabled attribute a standard boolean one.
Differential Revision: https://phabricator.services.mozilla.com/D220122
