On startup in my local build and mach run profile I see:

JavaScript error: chrome://browser/content/search/searchbar.js, line 164: TypeError: this._textbox is undefined

in the stderr, with the stack in the browser console being:

destroy chrome://browser/content/search/searchbar.js:164
    destroy self-hosted:1001
    disconnectedCallback chrome://browser/content/search/searchbar.js:366
    onDOMContentLoaded chrome://browser/content/browser.js:1469
    onDOMContentLoaded self-hosted:1003

This seems... very wrong.

Brian, I don't recall seeing this a week or two ago, any idea what changes might have tripped this?

The searchbar error here is being worked on in bug 1557869. I think this is probably a dupe?

(In reply to Mark Banner (:standard8) from comment #1)

The searchbar error here is being worked on in bug 1557869. I think this is probably a dupe?

Thanks. I'd prefer to morph this to be about the underlying problem that the disconnected code in the searchbar just exposes, so I'll do that.

I'm pretty sure we didn't use to pay this cost for XBL bindings, so we shouldn't pay it here. We shouldn't be initializing things that are in the palette at all, and should also not be disconnecting them.

Perhaps there's a (probably small) startup win here if we templatize the contents of the palette and don't un-templatize until customizableui needs something it can't find elsewhere?

(In reply to :Gijs (he/him) from comment #2)

Perhaps there's a (probably small) startup win here if we templatize the contents of the palette and don't un-templatize until customizableui needs something it can't find elsewhere?

Note that if we go this route, we probably want to optimize the case where there's an uninstalled extension (ie external buttons will never be in the template) in the placements, which would trip this un-templatizing, by hardcoding the list of items in the template somewhere.

We should be able to use html:template to avoid paying this cost.

https://hg.mozilla.org/mozilla-central/rev/f5f1227caf70