1357054 - 2.15ms uninterruptible reflow at _rebuild@chrome://browser/content/search/search.xml:1540:15

Status: RESOLVED INCOMPLETE

(Firefox :: Search, defect, P4)

Description

[Florian Quèze [:florian]]

The profiles in bug 1353725 show that the reflow is triggered by a .clientWidth call. I guess it's http://searchfox.org/mozilla-central/rev/d8496d0a1f6ebef57fe39b9b204475b0eccfb94c/browser/components/search/content/search.xml#1528

I think we should be able to do something here using getBoundsWithoutFlushing instead.

This currently happens whenever the awesomebar (or searchbar) panel opens. Once bug 1312999 is fixed, it'll be only the first time.

Here's the stack:

_rebuild@chrome://browser/content/search/search.xml:1540:15
handleEvent@chrome://browser/content/search/search.xml:1435:15
openPopup@chrome://global/content/bindings/popup.xml:53:15
_openAutocompletePopup@chrome://browser/content/urlbarBindings.xml:1617:11
openAutocompletePopup@chrome://browser/content/urlbarBindings.xml:1551:11
openPopup@chrome://global/content/bindings/autocomplete.xml:393:13
set_popupOpen@chrome://global/content/bindings/autocomplete.xml:103:10
notifyResults@jar:file:///Applications/FirefoxNightly.app/Contents/Resources/omni.ja!/components/UnifiedComplete.js:2111:5
_addMatch@jar:file:///Applications/FirefoxNightly.app/Contents/Resources/omni.ja!/components/UnifiedComplete.js:1733:5
_matchPlacesKeyword@jar:file:///Applications/FirefoxNightly.app/Contents/Resources/omni.ja!/components/UnifiedComplete.js:1381:5
TaskImpl_run@resource://gre/modules/Task.jsm:319:42
process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:922:23
walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:806:7
scheduleWalkerLoop/<@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:742:11

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Another similar stack:

_rebuild@chrome://browser/content/search/search.xml:1540:15
handleEvent@chrome://browser/content/search/search.xml:1435:15
openPopup@chrome://global/content/bindings/popup.xml:53:15
_openAutocompletePopup@chrome://browser/content/urlbarBindings.xml:1617:11
openAutocompletePopup@chrome://browser/content/urlbarBindings.xml:1551:11
openPopup@chrome://global/content/bindings/autocomplete.xml:393:13
set_popupOpen@chrome://global/content/bindings/autocomplete.xml:103:10
notifyResults@jar:file:///C:/Program%20Files/Nightly/omni.ja!/components/UnifiedComplete.js:2111:5
_addMatch@jar:file:///C:/Program%20Files/Nightly/omni.ja!/components/UnifiedComplete.js:1733:5
_onResultRow@jar:file:///C:/Program%20Files/Nightly/omni.ja!/components/UnifiedComplete.js:1636:5
_matchKnownUrl/<@jar:file:///C:/Program%20Files/Nightly/omni.ja!/components/UnifiedComplete.js:1336:7
handleResult@resource://gre/modules/Sqlite.jsm:774:13

Comment 2

[Alex Thayer [:alexical] (she/her)]

Given that it's only on the first open, I don't think this is a priority.

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Re-queuing for triage by fxperf to reconcile with qf evaluation.

Comment 4

[:Felipe Gomes (needinfo for replies!)]

For the reason mentioned in comment 2, I believe the most recent evaluation of this bug as fxperf:p3 stands.

Comment 5

[Mark Banner (:standard8)]

search.xml is now gone, just before it was removed, it didn't have a _rebuild method. Additionally, the address bar has been completely rewritten now, so if this is still an issue it'd need fresh stacks etc - they would probably be better dealt with in bug 1353725.

Comment 6

[Florian Quèze [:florian]]

I think this was fixed in bug 1578375.