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

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).

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).

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

(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?