785284 - tabbrowser and scrollbox calls getBoundingClientRect causing sync layout

Status: RESOLVED DUPLICATE of bug 1356705

(Firefox :: Tabbed Browser, defect)

Description

[Benoit Girard (:BenWa)]

MXR search:
http://mxr.mozilla.org/mozilla-central/search?string=getBoundingClientRect&find=%2Fbrowser%2Fbase%2Fcontent&findi=&filter=^[^\0]*%24&hitlimit=&tree=mozilla-central

I'm seeing tabbrowser.xml and scrollbox.xml cause some sync layout because of calls to getBoundingClientRect which is relatively a very expensive operation for a what looks like a simple getter.

Profile:
http://people.mozilla.com/~bgirard/cleopatra/?report=830af9dcdc0c1f36df7222a0da8a63827d8b0de5

Comment 1

[Dão Gottwald [:dao]]

I don't think I understand this bug. Are you suggesting that we should use something else than getBoundingClientRect, something that doesn't flush layout while still getting us the data we need?

Comment 2

[Benoit Girard (:BenWa)]

Yes, I'm not familiar with the code enough to know what the use case is for getBoundingClientRect but it would be ideal to avoid using it if it's not strictly required.

Comment 3

[Tim Taubert [:ttaubert] (inactive)]

Bug 878801 introduced nsIDOMWindowUtils.getBoundsWithoutFlushing(). We should investigate what possibilities we have and where we could replace getBoundingClientRect() calls.

Comment 4

[Dão Gottwald [:dao]]

For scrolling tabs into view and similar operations, we actually need up-to-date data.

Comment 5

[:Felipe Gomes (needinfo for replies!)]

We could look if some of this information can be cached by tabbrowser after the previous last operation finishes (e.g. width of tabs)

Comment 7

[Hazel Ward]

is bug 854054 a duplicate of this?