3.5ms uninterruptible reflow at _calcMouseTargetRect@chrome://browser/content/tabbrowser.xml:7763:27 when the status text changes

RESOLVED FIXED in Firefox 55

Status

()

Firefox
Tabbed Browser
P1
normal
RESOLVED FIXED
10 days ago
2 days ago

People

(Reporter: mconley, Assigned: dao)

Tracking

(Blocks: 2 bugs)

unspecified
Firefox 55
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify -

Firefox Tracking Flags

(firefox55 fixed)

Details

(Whiteboard: [ohnoreflow][qf][photon-performance])

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

(Reporter)

Description

10 days ago
Here's the stack:

_calcMouseTargetRect@chrome://browser/content/tabbrowser.xml:7763:27
set_label@chrome://browser/content/tabbrowser.xml:7713:13
updateStatusField@chrome://browser/content/browser.js:4513:7
_showDelayed/this._timer<@chrome://browser/content/browser.js:4922:7
(Assignee)

Updated

9 days ago
Flags: needinfo?(dao+bmo)
Flags: qe-verify?
Priority: -- → P2
(Assignee)

Comment 1

8 days ago
I think this is basically unavoidable. We can call _calcMouseTargetRect more lazily in getMouseTargetRect, but this will only make a difference for the resize event handler. With the stack from comment 0, MousePosTracker will immediately call getMouseTargetRect anyway (it has to).
Flags: needinfo?(dao+bmo)
Comment hidden (mozreview-request)
(Assignee)

Updated

8 days ago
Assignee: nobody → dao+bmo
Status: NEW → ASSIGNED
(Assignee)

Updated

8 days ago
Flags: qe-verify? → qe-verify-
Priority: P2 → P1

Comment 3

6 days ago
mozreview-review
Comment on attachment 8858607 [details]
Bug 1356663 - Calculate the status panel's mouse target rectangle lazily in getMouseTargetRect.

https://reviewboard.mozilla.org/r/130604/#review133854

r=me because this is an improvement over the current state, but I think we can do better.

How much effort would it be to add a listener for a bigger target that would have the height of the statusbar panel (we can get this value without sync flush, right?) and the full width of the content area? And then only if that bigger area is entered by the mouse, compute the exact size of the rect we care about and set another listener for that specific area. MousePosTracker may need a few changes to make this work (eg. to notify immediately a listener for an area that is already hovered at the time the listener is added).
Attachment #8858607 - Flags: review?(florian) → review+

Comment 4

6 days ago
Pushed by dgottwald@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c5bdfc3ba44d
Calculate the status panel's mouse target rectangle lazily in getMouseTargetRect. r=florian
(Assignee)

Comment 5

6 days ago
(In reply to Florian Quèze [:florian] [:flo] from comment #3)
> Comment on attachment 8858607 [details]
> Bug 1356663 - Calculate the status panel's mouse target rectangle lazily in
> getMouseTargetRect.
> 
> https://reviewboard.mozilla.org/r/130604/#review133854
> 
> r=me because this is an improvement over the current state, but I think we
> can do better.
> 
> How much effort would it be to add a listener for a bigger target that would
> have the height of the statusbar panel (we can get this value without sync
> flush, right?)

Actually no, there's no parent or sibling node with the same height as the statuspanel is position:fixed.
(In reply to Dão Gottwald [::dao] from comment #5)

> > How much effort would it be to add a listener for a bigger target that would
> > have the height of the statusbar panel (we can get this value without sync
> > flush, right?)
> 
> Actually no, there's no parent or sibling node with the same height as the
> statuspanel is position:fixed.

Could we remember that height the first time we get it? And maybe get it using getBoundsWithoutFlushing (and fallback to flushing only if the value we got from getBoundsWithoutFlushing is 0) ? This height doesn't change, right?

Comment 7

5 days ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/c5bdfc3ba44d
Status: ASSIGNED → RESOLVED
Last Resolved: 5 days ago
status-firefox55: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 55
Iteration: --- → 55.4 - May 1
(Reporter)

Updated

5 days ago
See Also: → bug 1354194
(Assignee)

Updated

3 days ago
Duplicate of this bug: 1358426
Depends on: 1358712
Summary: 3.5ms uninterruptible reflow at _calcMouseTargetRect@chrome://browser/content/tabbrowser.xml:7763:27 → 3.5ms uninterruptible reflow at _calcMouseTargetRect@chrome://browser/content/tabbrowser.xml:7763:27 when the status text changes
(Assignee)

Updated

2 days ago
Blocks: 1358712
No longer depends on: 1358712
You need to log in before you can comment on or make changes to this bug.