GreaseKit does not load scripts at a consistent time

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install the attached script (that expects to modify an object created in the 
onload() event).
2. Navigate to https://online.hbs.net.au/HBSV45/NTV45.ASP?WCI=entry
3. Go Back, then Forward.

What is the expected output? What do you see instead?
The keyboard should be hidden (though it may briefly become visible). With 
Creammonkey 0.7 
this worked reliably. With GreaseKit this is not reliable. (Re)loading the page 
seems to run the 
script before the onload() event most of the time. Going Back then Forward 
seems to run the 
script after the onload() event most of the time.

What version of the product are you using? On what operating system?
GreaseKit 1.3 on Safari 3.0.4 (whatever comes with Mac OS X 10.4.11).

Please provide any additional information below.
I had a look at the code and the problem seems to be caused by the call to
  [self evalScriptsInFrame: [webView mainFrame] force: NO];
in CMController -progressChanged. By commenting that line out, I could build a 
GreaseKit that 
operated the same way Creammonkey 0.7 did.

Original issue reported on code.google.com by a1291...@gmail.com on 4 Dec 2007 at 10:24

Attachments:

• heritage_test.user.js

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thank you for reporting.

Original comment by kato.kaz...@gmail.com on 25 Dec 2007 at 1:46

• Added labels: Type-Patch
• Removed labels: Type-Defect

[GoogleCodeExporter]

While investigating how Chrome handles userscripts I noticed that it loads 
scripts in a nondeterministic 
manner too. On a hunch, I checked and it seems the same code that works under 
Chrome works under 
GreaseKit.

The code is this:

if (document.readyState == "complete") {
    myfunc();
} else {
    window.addEventListener("load", myfunc, false);
}

When the onload() has already fired, document.readyState is set to "complete" 
so the script can do work 
straight away. Otherwise, the script knows to wait for onload to fire.

Since scripts can be updated to deal with this non-deterministic loading and 
since it's required for scripts to 
run under Chrome I suspect this bug should be closed as wontfix.

Original comment by a1291...@gmail.com on 14 Apr 2010 at 1:36