It's not clear that there is any user-visible bug here but it is causing unnecessary work and can
cause debugging to be harder than it needs to be.
Differential Revision: https://phabricator.services.mozilla.com/D202790
When called with isLink=true, _getDragTargetTab returns null if the
pointer is around the edges of the tab. This is useful to decide whether
drag-and-drop should create a new tab, or reuse an existing one.
The problem was that _getDropIndex, used when creating a new tab, would
therefore always get a null tab on dragover events, and then fall back
to iterating all tabs sequentially until it would find the right index,
with an expensive getBoundingClientRect() for each tab.
So this patch:
- Renames unclear isLink to a more meaningful ignoreTabSides
- Makes _getDragTargetTab use the native Element#closest instead of
iterating the ancestors manually in JS.
- Makes _getDropIndex always pass ignoreTabSides=false
- Refactors _getDropIndex to never iterate tabs.
- Adds .tab-drop-indicator{pointer-events:none}. This is needed so that
the indicator doesn't become the event target, we want to get the tab
behind it.
Differential Revision: https://phabricator.services.mozilla.com/D166125
This adds probes and a limited set of tests for the following types of measurements:
1. A count for each time the All Tabs panel is opened, keyed on the entrypoint.
2. A count for each usage of the Tab Context Menu, keyed on the trigger node
as the entrypoint.
3. A count for each dragstart within the All Tabs panel.
Differential Revision: https://phabricator.services.mozilla.com/D168305
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
