1181333 - set_selectedIndex() @ tabbrowser.xml:6105 triggers a frame during tab switch

Status: NEW

(Firefox :: Tabbed Browser, defect, P3)

Description

[Benoit Girard (:BenWa)]

NOT A PERF PROFILE! I got a 'profile' logging everything that is hitting PresContext when changing: http://people.mozilla.org/~bgirard/cleopatra/#report=7c25e25f5269f8e0d5effcad7bca71b8d691b330

Looks like 'set_value() @ autocomplete.xml:269' is responsible for the first extra frame we see during tab switch time. This is hurting our tab switch time because we're painting an intermediate frame that doesn't include the tab content.

In optimized builds this function still shows up as also taking a lot of direct CPU time in addition to trigger the refresh driver to run later.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

That autocomplete.xml binding is certainly the one belonging to the URL bar, which we update synchronously with the URL of the tab that we're switching to.

Comment 2

[Benoit Girard (:BenWa)]

Here's a better view into the profile:
http://people.mozilla.org/~bgirard/cleopatra/#report=7c25e25f5269f8e0d5effcad7bca71b8d691b330&filter=[{%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A20280,%22end%22%3A20484}]

Comment 3

[Mike Conley (:mconley) (:⚙️)]

One thing we might want to try is to not update the URL bar (and the rest of the navigation-toolbox) until the tab frame is ready to paint. That would, theoretically, allow us to avoid painting at _least_ one frame and blocking the main process, which gives the content process greater lee-way in sending sync messages.

We'd have to come up with some kind of solution for the case where the tab we're switching to needs to have the URL bar focused so as to not lose any key events.

Comment 4

[Brad Lassey [:blassey] (use needinfo?)]

BenWa, to the best of my recollection I started working on suppressing paints during tab switch which improved tab switching at first. Then other stuff landed and it was a wash. So... I guess I'm asking if this is still a problem.

Comment 5

[Benoit Girard (:BenWa)]

If we implement paint suppression properly then all sub bugs of bug 1180916 should be fixed since we can't paint by definition. AFAIK it still hasn't shipped so this bug is likely still here.

Comment 6

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information