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.
Can you pingback my site with this please? Thanks for staying with this BTW.
Comment by Dean Edwards [Visitor] — June 27, 2006 @ 4:38 pm
Guys, I’ve updated my Object Literal version to address the following:
allows multiple calls
also (sorta) resolves the IE/HTTPS issue
Let me know what you think.
Comment by Rob Cherny [Visitor] — July 3, 2006 @ 8:15 am
Hmmm … Looking at your latest of course, I guess the location.protocol test could toggle between http: and https: based on the test, and not have to rely on the external file again?
Yeah. If I get some time I’ll test that…
Comment by Rob Cherny [Visitor] — July 3, 2006 @ 8:21 am
I don’t think you even need to toggle between http: and https:. You can just always use https:.
Comment by Matthias Miller [Member] — July 3, 2006 @ 9:06 am
Well done, and for spotting that src=0 generates a request we don’t want.
You can save yourself a few bytes by doing src=//0.
I have updated my test page: https://www.partyark.co.uk/html/ie7b3success.asp
A
Comment by Alistair Potts [Visitor] — July 6, 2006 @ 2:17 pm
Regarding your obvservation that Firefox tries to resolve src=//: - I’m sure you’re right, but this code is only for IE anyway! Which means, by an infinitessimally pedantic margin, I think my solution wins for not returning anything at all.
(not that any of this would have been possible without all your work anyway)
Anyway…
Comment by Alistair Point [Visitor] — July 17, 2006 @ 2:00 pm
Pretty much agreed–I’m certainly glad for your testing here. The problem with Firefox attempt to resolve is that it the throbber keeps going until it times out, so the script needs to be written out for IE only.
And meanwhile, I’m stubbornly holding out until the IE7 RC to see how they’ve fixed the URL resolution bug.
Comment by Matthias Miller [Member] — July 18, 2006 @ 4:57 am
Try to replace the bit of code for IE with this in a setTimeout loop:
if (document.activeElement) { fire_event(); }Or by using the related event:
document.attachEvent('onactivate', fire_event);It worked like a charm for me and also fixes the Back Button problem.
Please if you have a test case that does not work submit it.
I can’t believe it something so easy existed, but I tested and it works…
Waiting for your confirmation tests…
Comment by Diego Perini [Visitor] — July 29, 2006 @ 5:36 pm
Based on the MSDN documentation, I really like what I see. I’m eager to run a number of tests on it next week.
Are you concerned about behavior in IE4? When does onactivate get fired for that version?
Comment by Matthias Miller [Member] — July 29, 2006 @ 7:30 pm
From what they have in their docs:
The difference with IE4 is that while loading, the
document.activeElementis set to be the BODY object instead of NULL like in IE 5 and later.However we will still have an “onbeforeactivate” if that still don’t work in IE 4…
Everything is bound to the FOCUS mechanism and I really tested that also the “onfocus” events are fired during the loading process on the window, on the document and on the body objects.
Comment by Diego Perini [Visitor] — July 30, 2006 @ 3:16 am
[...] Update: Applying fixes for HTTPS. [...]
Pingback by The window.onload Problem Revisited « Out of Hanwell — September 20, 2007 @ 10:05 pm