BrowserNewTabPreloader needs to query tabbrowser bounds without flushing pending layout changes

RESOLVED FIXED in Firefox 24

Status

()

defect
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: ttaubert, Assigned: ttaubert)

Tracking

({dev-doc-needed})

Trunk
Firefox 24
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

Silly me introduced another uninterruptible reflow while fixing bug 875257. The BrowserNewTabPreloader must not query window.gBrowser.boxObject when opening new tabs or else this will again cause us to flush pending layout changes.
This patch adds .getBoundsWithoutFlushing() to nsIDOMWindowUtils which is the equivalent to DOMElement.getBoundingClientRect() without flushing pending layout changes.
Attachment #757404 - Flags: review?(roc)
I forgot to note that it's totally ok for the BrowserNewTabPreloader to work with bounds that are possibly not up-to-date as we're optimizing for the average case where a user does not resize their window every time before opening a new tab (even if so there's a good chance something else will flush the layout for us). The code does still work with "incorrect" bounds.
Comment on attachment 757405 [details] [diff] [review]
part 2 - query tabbrowser bounds without flushing layout

Review of attachment 757405 [details] [diff] [review]:
-----------------------------------------------------------------

rs=me
Attachment #757405 - Flags: review?(jaws) → review+
https://hg.mozilla.org/mozilla-central/rev/40216a220b80
https://hg.mozilla.org/mozilla-central/rev/ce5ab0de1b09
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 24
Depends on: 879733
Depends on: 881661
You need to log in before you can comment on or make changes to this bug.