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

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

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

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

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