Closed Bug 1506237 Opened 6 years ago Closed 6 years ago

Delay search-one-offs connectedCallback

Categories

(Firefox :: Search, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 65
Tracking Status
firefox65 --- fixed

People

(Reporter: bgrins, Assigned: bgrins)

References

Details

Attachments

(2 files)

I'm seeing this show up in profiles: https://searchfox.org/mozilla-central/rev/a3894a4dcfb5d42f2e6eee6cb9faf7141879ef1a/browser/components/search/content/search-one-offs.js#185. It should be delayed until after DOMContentLoaded and we should probably share the fragment too, since it appears we create more than one of these.
Hmm, we should probably create these elements on the fly when opening the parent popups.
Using: `./mach talos-test -a tpaint --geckoProfile` Without patches: https://perfht.ml/2zG1U0D. 9ms and two separate groups of work. With patches: https://perfht.ml/2zH6ETF. 4ms and one group of work.
It's best practice in chrome to not run code in the connectedCallback during parse (see the comment above MozXULElement.delayConnectedCallback).
This avoids the cost to parse the markup for subsequent connections.
(In reply to Dão Gottwald [::dao] from comment #1) > Hmm, we should probably create these elements on the fly when opening the > parent popups. Yeah, that would be good as well since there's quite a bit of work to do upon construction / connection. I'm guessing if we go away from a Custom Element and towards a plain JS class that would solve this issue.
Pushed by bgrinstead@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/65a4195373c8 Delay search-one-offs connectedCallback;r=dao https://hg.mozilla.org/integration/autoland/rev/9edb93a822c3 Share document fragment for search-one-offs between instances;r=dao
Blocks: 1506261
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 65
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: