Rob mentioned that the window.onload solution generates a secure/nonsecure warning when used over a secure connection. This is because the script’s src references the “javascript:” scheme instead of “https:”.
I pointed the script’s src to “https:///”, a URL that obviously does not exist, and ran the script against several automated and manual tests. Oddly, onreadystatechange no longer gets fired for the “loading” state, but all tests did pass as expected. (These were the same tests that I used to verify the original proposal.)
I would have posted a comment on Dean’s blog to interact about this, but it looks like his site is temporarily unavailable. I’ve done my best to test this and it works for me, but let me know what you all find.
Update: This does not work in IE7b3 because of a regression in URL resolution. It attempts to resolve “https:///” relative to the current domain, thus loading “https://domain/” instead. After some testing, I found that it does not attempt to resolve invalid IPv6 URLs, such as “https://[]/”. Also, the URL scheme is optional, so the script can point to “//[]“.
Update: Internet Explorer 6 does try to resolve “//[]“. Alistair Potts suggested using “//0″ instead–which appears to be the equivalent of “//0.0.0.0″, based on behavior in IE7–and later pointed out that Internet Explorer does not even attempt to resolve “//:”. Firefox, however, does attempt to resolve “//:”, causing an inconvenient status until it times out.