1362542 - 4.26ms uninterruptible reflow at _updateTabsVisibilityStatus@chrome://browser/content/tabbrowser.xml:7481:1

Status: RESOLVED FIXED

(Firefox :: Tabbed Browser, enhancement, P1)

Description

[Stefan Fleiter (:sfleiter)]

Here's the stack:

_updateTabsVisibilityStatus@chrome://browser/content/tabbrowser.xml:7481:1
onxblpopupshowing@chrome://browser/content/tabbrowser.xml:7591:11

Comment 1

[Stefan Fleiter (:sfleiter)]

Happens when clicking on the down arrow (listing open tabs) right next to the new tab button every time for me

Comment 2

[Dão Gottwald [:dao]]

Attachment: Bug 1362542 - Avoid flusing layout when updating tabs' visiblity status for the overflow menu.

Review commit: https://reviewboard.mozilla.org/r/143176/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/143176/

Comment 3

[Dão Gottwald [:dao]]

Comment on attachment 8871655 [details]
Bug 1362542 - Avoid flusing layout when updating tabs' visiblity status for the overflow menu.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/143176/diff/1-2/

Comment 4

[Florian Quèze [:florian]]

Comment on attachment 8871655 [details]
Bug 1362542 - Avoid flusing layout when updating tabs' visiblity status for the overflow menu.

https://reviewboard.mozilla.org/r/143176/#review147528

Thanks for looking at this! The patch looks reasonable, but I have a question:

_updateTabsVisibilityStatus is called both from the popupshowing event handler, and from a 'scroll' event listener. For the popupshowing case, the user hasn't interacted very recently with the tab strip so I think there's no doubt that getBoundsWithoutFlushing will get correct results. For the case where the user scrolls through the tab strip while the panel is open, I'm less sure (I can't test this on Mac where the native menu popup eats all mouse events). Have you verified that scrolling the tabstrip still updates the visible tabs correctly? If not, do we need to call _updateTabsVisibilityStatus from a MozAfterPaint listener for the 'scroll' case?

Unrelated to what the patch changes: I wonder how this code performs when there are many tabs. Would adding a binary search for the position of the first visible tab be worth the effort (potentially in a follow-up)?

Comment 5

[Dão Gottwald [:dao]]

(In reply to Florian Quèze [:florian] [:flo] (away until Monday May 29th) from comment #4)
> Comment on attachment 8871655 [details]
> Bug 1362542 - Avoid flusing layout when updating tabs' visiblity status for
> the overflow menu.
> 
> https://reviewboard.mozilla.org/r/143176/#review147528
> 
> Thanks for looking at this! The patch looks reasonable, but I have a
> question:
> 
> _updateTabsVisibilityStatus is called both from the popupshowing event
> handler, and from a 'scroll' event listener. For the popupshowing case, the
> user hasn't interacted very recently with the tab strip so I think there's
> no doubt that getBoundsWithoutFlushing will get correct results. For the
> case where the user scrolls through the tab strip while the panel is open,
> I'm less sure (I can't test this on Mac where the native menu popup eats all
> mouse events). [...]

This doesn't work on any platform. I'll remove the scroll event listener.

Comment 6

[Dão Gottwald [:dao]]

Comment on attachment 8871655 [details]
Bug 1362542 - Avoid flusing layout when updating tabs' visiblity status for the overflow menu.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/143176/diff/2-3/

Comment 7

[Florian Quèze [:florian]]

Comment on attachment 8871655 [details]
Bug 1362542 - Avoid flusing layout when updating tabs' visiblity status for the overflow menu.

https://reviewboard.mozilla.org/r/143176/#review147666

Thanks!

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/90075cb286d6
Avoid flusing layout when updating tabs' visiblity status for the overflow menu. r=florian

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/90075cb286d6