window.onload

[jsocol]

Chrome's version (at least the port to Windows) runs well before the window load event fires. This, as with all pageMods from the Add-on SDK, runs after.

(NB: I prefer after, since I can just manage the DOM as it already exists, but, meh.)

It's worth considering finding a way to make these compatible. The issue I ran into is that for Chrome, I need to add an onload handler, and for Firefox, load has already fired before this runs, so adding a handler doesn't work.

If I'm the only one to hit this, it's probably the chrome dotjs Windows port's fault.

[rlr]

@canuckistani any ideas for this?

I wonder if there is a sneaky way to look at the window load event handlers before and after we inject the scripts and directly call the new ones.

[jeffgca]

Here's the SDK bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=787063

Basically, no. Also, and I freel yadmit this is an implementation detail, window.onload if we supported it is dangerously misleading in a content script. Content scripts are in their own sandbox so window is actually a proxy. If we let a content script set the real window.onload this would do two things:

1. override whatever was set there ( although real web hackers don't use window.onload anyway )
2. open up a channel between the real window and the content script, possible creating a security problem.

Dunno, IMO window.onload use causes the death of many many kittens at the hands of a ruthless and bloodthirsty old-testament-type god. I can't recommend it.

We could play around with using contentScriptWhen: 'start', for example, but I don't think that will do what we want most of the time.