gBrowser.tabs was either redirecting to gBrowser.tabContainer.allTabs or
using the previously cached result. However, most tabContainer code uses
allTabs directly, which was not benefiting from the cache.
Therefore, this patch caches gBrowser.tabContainer.allTabs, and makes
gBrowser.tabs always redirect to it.
Also makes it consistent for gBrowser.tabContainer._getVisibleTabs() and
gBrowser.visibleTabs. In that case both the logic and the cache were in
gBrowser, and tabContainer was redirecting to that, except when gBrowser
hadn't been initialized.
So it's better to have both the logic and the cache in tabContainer.
Differential Revision: https://phabricator.services.mozilla.com/D166962
Calling _mouseleave and _mouseenter from _setPositionalAttributes used
to be needed to update the beforehovered and afterhovered attributes,
as the tabs these attributes were set on might have changed.
However, bug 1808661 removed these attributes, so mouseenter/mouseleave
events should be sufficient for updating _hoveredTab itself.
_setPositionalAttributes is a hot code-path, so avoiding the expensive
querySelector("tab:hover") will improve performance when having lots of
tabs.
Depends on D166094
Differential Revision: https://phabricator.services.mozilla.com/D166225
This removes the `intl:app-locales-changed` event listener that was added in bug 1760825, as it's not longer required.
Depends on D159017
Differential Revision: https://phabricator.services.mozilla.com/D159018
This was introduced alongside the MutationObserver[1], according to the commit
message to "improve performance through coalesence of 'resize' events."
However, that's false, before this bug, resizes on the top level window would
flush layout and resize the document element instantly so there should be the
exact same amount of resize events as of ResizeObserver notifications. I'm not
sure what coalesence would this achieve.
This is causing the previous patch to get backed out, due to a failure on macOS
that I haven't been able to reproduce.
It's likely because on chrome windows some document element resizes can trigger
window resizes due to the size constraint propagation we have, so nothing
super-concerning or new all-in-all, my patch just changed the timing of how
this happened.
[1]: https://hg.mozilla.org/mozilla-central/rev/ad71dde9ed5e28957b124001a78c88fc1d94426a
Differential Revision: https://phabricator.services.mozilla.com/D155986
The root cause of the bug is fixed by the previous patch. This patch improves
the calculations to work properly across mixed dpi displays (which doesn't work
on release either by any stretch).
Hopefully it's somewhat straight-forward to follow.
Depends on D139243
Differential Revision: https://phabricator.services.mozilla.com/D139244
Device pixels and desktop pixels are not the same on macOS and Win7.
Expose the desktop-to-device scale to JS and use it appropriately.
Depends on D138038
Differential Revision: https://phabricator.services.mozilla.com/D138039
Device pixels and desktop pixels are not the same on macOS and Win7.
Expose the desktop-to-device scale to JS and use it appropriately.
Depends on D138038
Differential Revision: https://phabricator.services.mozilla.com/D138039
It does the same as window.devicePixelRatio. However a bunch of this
code is copy-pasted code trying to scale a canvas, but not messing with
full zoom is the right thing to do.
The full zoom value in the top level browser.xhtml page is always 1
anyways, and WindowsPreviewPerTab looking at the current browser tab's
full zoom is just bizarre...
Differential Revision: https://phabricator.services.mozilla.com/D138020
screenForRect takes screen coordinates (device pixels, for our purpose here).
However screenX / screenY are in CSS pixels, so we need to convert them to the
right coordinate space before looking up the screen.
Differential Revision: https://phabricator.services.mozilla.com/D137895
Otherwise, callers might end up unintentionally binding the browser for lazy background tabs.
This was happening when a11y queried the LABEL_FOR relation while building the a11y tree, causing all lazy tabs to be loaded.
All callers of this method only need it to insert a browser when the tab is selected anyway.
Differential Revision: https://phabricator.services.mozilla.com/D114566
