search

rlr / dotjs-addon

[unmaintained] ~/.js for Firefox
BSD 3-Clause "New" or "Revised" License
144 stars 17 forks source link

window.onload #21

Open jsocol opened 11 years ago

jsocol commented 11 years ago

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 commented 11 years ago

@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 commented 11 years ago

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.