1451974 - opening/closing tab overflow menu *very* slow/janky due to custom elements code

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Recently I'm seeing that opening/closing the tab overflow menu (i.e., the dropdown at the right end of the tab bar that gives access to the tabs that don't fit) in a window with a large number of tabs is *very* slow/janky.  A profile shows that the problem is in custom elements code: https://perfht.ml/2q8m8ve .  The bulk of the time seems to be spent in mozilla::dom::CustomElementRegistry::UnregisterUnresolvedElement and (mostly) a QueryInterface inside it.

Myk suggests the proximate cause of the regression may be bug 1421070, though presumably the problem is older.  Not sure who the right person to investigate here is.

Comment 1

[Brian Grinstead [:bgrins]]

This is probably due to Bug 1446247.

Comment 2

[Brian Grinstead [:bgrins]]

There's an off chance that the fix from Bug 1451340 will help here if it turns out to be scrollbar related

Comment 3

[Brian Grinstead [:bgrins]]

:smaug - I won't be able to look at this until next week, but is there anything in the profile that stands out to you? Unless if you think there's a general CE optimization to be made I guess we can introduce a blacklist of tag names like in https://reviewboard.mozilla.org/r/228226/diff/2/. Or possibly switch to a whitelist that gets updated right before we do a migration (although I'd prefer to not do this because it makes the frontend changes more inconvenient).

Comment 4

[Brian Grinstead [:bgrins]]

Or maybe we could bypass elements that already have a XBL binding attached in the same way we did with IsInNativeAnonymousSubtree in Bug 1451340.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

We need to figure some other setup for XUL than blacklisting.

Obviously we want to back out bug 1446247 for now.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

CustomElementRegistry::UnregisterUnresolvedElement looks like a huge performance problem, though -- a linear scan of an array, doing a QueryReferent on each element to test for a match?  Removing everything is O(N^2) in the number of elements in the array.  Isn't that what's happening here?  That doesn't seem like acceptable performance characteristics, XUL or not.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(For the record, I have about 1550 tabs in my browser window.)

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

there is a bug filed to improve that.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

and bug 1446247 was backed out, so this is fixed.

Comment 10

[Dave Townsend [:mossop]]

(In reply to Olli Pettay [:smaug] (only webcomponents and event handling reviews, please) from comment #8)
> there is a bug filed to improve that.

Which bug?

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

bug 1452074