Remove the overlayTriger binding.

Looking at this more closely, I'm not sure what it's supposed to do.

It creates an element, then appends that to the document. Loads the css for the xbl, so the element would get binding attached. That causes the custom event, which the event listener reacts to.

Unless there's some side effect I don't see here, it looks rather pointless, and more of a game to win some time?

At least lightning seems ok with this.
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=3424f6971806038e49f03f00e1afa0cba1aca371

I have a bad feeling about doing this. What that code is supposed to do is delay the fake load event we send to listeners in the event of an overlay being applied after the real load event, which happens in some circumstances. We wait for a stylesheet to load and a binding to be constructed so that we can assume all stylesheets have loaded and all bindings have been applied.

I'm going to make a build and try this on one of my VMs, as it used to run this bit of code frequently.

I guess the question is, why do we need to wait for all stylesheets or bindings to be applied? If it's purely about bindings (which would be applied through stylesheet hookup) then for any overlay loading this is just not something we'd support anymore in 68. For 68 add-ons xbl bindings can be considered dead, and there's hope we're not really even using them in the core product for anything.

We might want to delay landing it until calendar xbl is further done, just to be sure.

This is engineering, so => task https://wiki.mozilla.org/BMO/UserGuide/BugFields#bug_type

Lets get this landed. Good try at https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=c2e4cbe9650b6e90e5a73b303c9694994a802293

Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/44e0b7bccc36
[de-xbl] remove the overlayTrigger binding. r=darktrojan

This is really a Calendar bug fixed at 7.1.