Closed Bug 269754 Opened 21 years ago Closed 16 years ago

<Body onload> fails to execute with HTTPS

Categories

(Core :: DOM: Events, defect)

Product:
Core
Component:
DOM: Events
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: rod, Unassigned)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040924 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040924 The page at http://www.refercare.org/onload.html correctly displays an "alert" popup invoked via the onload event. However if you use SSL (https instead of http), the onload is not invoked and so there is no popup. Reproducible: Always Steps to Reproduce: 1. Visit https://www.refercare.org/onload.html 2. Observe that there is no alert 3. Visit http://www.refercare.org/onload.html 4. Observe that there is an alert Actual Results: As described. Expected Results: Step 2 should show an alert popup. Here is the source: <html> <head> <title>Test OnLoad</title> <script language="JavaScript"> function imloaded() { alert('Onload() worked!'); } </script> </head> <body onload="imloaded()"> <p>If you didn't get a popup message, then onload failed.</p> </body> </html>
WFM Mozilla 1.8a4 WinXP
(In reply to comment #1) > WFM Mozilla 1.8a4 WinXP That sounds encouraging. I see the same bug in Firefox 1.0 for Linux, WinXP and Win98.
WFM, Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
(In reply to comment #2) > > I see the same bug in Firefox 1.0 for Linux, WinXP and Win98. wfm Mozilla/5.0 (Windows; U; Win98; de-DE; rv:1.7.5) Gecko/20041108 Firefox/1.0 wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041113
wfm with a current cvs trunk build you don't have any strange extensions/content blockers installed?
(In reply to comment #5) > wfm with a current cvs trunk build > you don't have any strange extensions/content blockers installed? No... in the cases of Firefox on Win98 and WinXP these are fresh installs of 1.0 onto vanilla platforms. The Linux Firefox is a 1.0 prerelease (the current Gentoo binary). Linux Mozilla is 1.7.3. The only thing these all have in common is my LAN with its Linux router/gateway/firewall and its DSL connection. There's some packet filtering going on but the viewed source looks good and I can work around the problem by modifying the HTML to invoke the JavaScript function at the end of the HTML instead of via onload. I'm very surprised by all the WFM's.
Here's a bit more information. I installed Mozilla 1.8a4 on Win98 and could not get it to fail. Also contrary to my original submission, the problem occasionally does not appear on my Linux test setup with Mozilla 1.7.3. I.e. it seems to be a "hyperbug" with no obvious conditions as to when it does or does not happen. It seems likely to have been fixed in 1.8 but it would be nice if there were an explanation for that.
> seems to be a "hyperbug" with no obvious conditions as to when it does or does > not happen. It seems likely to have been fixed in 1.8 but it would be nice if > there were an explanation for that. I'd really like to see a bit of investigation into this as well. I see this bug regularly, and it's really annoying so I'd like to make sure it's definitely fixed in the future. It does seem to be heavily timing related. I have a website setup on my home network, on an external development server, and on our production server, and it appears much more on the later two than on the first, and the rate it seems to occur does change over time, so it seems related to time it takes to load the page or something. Very strange and hard to reproduce.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 The first time I opened the https link the page did not load an alert, after that I opened the http link and the alert did show. Then I loaded the https link again (and again) and now the alert did show! When I opened the https page in a 20050206 Firefox nightly trunk build with a new profile, the page loaded an alert at first try.
(In reply to comment #0) Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Firefox/1.0.4 I have the same problem :-(, so I investigate a little using your test page onload.html. I'm trying to certificate my company's website as compatible with firefox (actually it's certified only for MSIE.) but, in some case (apparently random), I can see only a blank page. I have noticed when this happen the page's source contains always an onload() that should submit a form and redirect the user to an other page. I spent much time trying to understand this strange problem, now I can reproduce this bug. The test page must be on an 1) HTTP webserver (apache/IIS) behind an 2) HTTPS reverse-proxy (apache-2) from https to http with 3) HTTP/1.1 enabled and 4) keep-alive enabled (web-server and reverse proxy MUST be on different machines) and the client must be directly connected to internet (if you use a proxy like squid this page works fine). If you press SHIFT-reload many times you can see the bug (sometime the pop-up appears and sometime not!) - If you use another browser rather than Firefox/Mozilla the page works ALWAYS fine. - If you use http instead of https or disable keep-alive the page works ALWAYS fine. - If you bypass the reverse proxy using the address of the web-server the page works ALWAYS fine. You can try this URLs: - behind a reverse proxy: https://webcert.bpvnsgs.it/bpn/newcert/onload.html - without the rev-proxy: https://trade.bpv.it/mozilla_firefox/onload.html See this screenshots: https://trade.bpv.it/mozilla_firefox/firefox_onload.png https://trade.bpv.it/mozilla_firefox/mozilla_onload4.png (behind the rev-proxy the onload() does not starts) https://trade.bpv.it/mozilla_firefox/firefox_onload1.png https://trade.bpv.it/mozilla_firefox/mozilla_onload2.png (after some refresh the pop-up appears) https://trade.bpv.it/mozilla_firefox/firefox_onload3.png https://trade.bpv.it/mozilla_firefox/mozilla_onload.png https://trade.bpv.it/mozilla_firefox/mozilla_onload3.png (behind the rev-proxy the onload() does not starts and the output is wrong) https://trade.bpv.it/mozilla_firefox/firefox_onload2.png (without rev-proxy onload() starts and the pop-up appears) If you don't use all the features in this list: -Mozilla/Firefox -reverse-proxy -HTTPS -HTTP/1.1 -Keep-Alive or if you use a proxy to browse internet the problem disappears.... I tried Mozilla and Firefox on Linux, Win2k and MacOS X. The results are the same! A little work-around I found is using the apache BrowserMatch directive to disable the keep-alive if the browser is Firefox or Mozilla.... this is very ugly! There are some bugs apparently related to this: #199281, #173019, #258490, I think the state of this bug can be changed to NEW. Bye Fabio
(In reply to comment #10) > - behind a reverse proxy: https://webcert.bpvnsgs.it/bpn/newcert/onload.html WFM with Firefox 20050513 trunk build. Fails to work with Firefox 1.0.4 I think this has been fixed on trunk by bug 227976. From bug comments, it appears the fix never made onto the branch build. http://archive.mozilla.org/pub/firefox/nightly/2004-06-16-09-trunk/ build fails. http://archive.mozilla.org/pub/firefox/nightly/2004-06-18-09-trunk/ build works. This bug needs to be reassigned to "Core: Networking HTTP"
Bonsai comment: 2004-06-16 09:28 darin%meer.net fixes bug 227976 "nsHttpCompressConv can fail to read any data in OnDataAvailable and return success" r=biesi (patch based on suggestion by bzbarsky)
Just an FYI, if anyone searching for this problem comes across this bug, the current workaround I have in place for Firefox only browsers is: In the <head> section: <script type="text/javascript"><!-- var OnLoadHasRun = 0; function DoOnLoad() { if (!OnLoadHasRun) { OnLoadHasRun = 1; DoOnLoadStuff(); } } function DoOnLoadStuff() { ... your old onload stuff here ... } --></script> In your <body> tag: <body onload="DoOnLoad();" ...> Just before the </body> end tag: <script type="text/javascript"><!-- var NumTimes = 50; function TestOnLoad() { var FoundDiv = document.getElementById('ffbug'); if (FoundDiv) { DoOnLoad(); } else if (--NumTimes > 0) { setTimeout("TestOnLoad();", 50); } } setTimeout("TestOnLoad();", 10); --></script> <div id="ffbug" style="position: absolute; visibility: hidden; display: none"></div> It's hacky, but it basically seems to work.
(In reply to comment #13) nsHttpCompressConv.... sounds like a bug related to the mod_gzip.... I set network.http.accept-encoding to "" in about:config disabling the gzip/deflate and the page loads always fine. I will try to set a BrowserMatch directive to set the same thing server side.
(In reply to comment #13) > Just an FYI, if anyone searching for this problem comes across this bug, the > current workaround I have in place for Firefox only browsers is: Another workaround is BrowserMatch Firefox/1\.0\.[01234] no-gzip in apache configuration. It disables the compression only for Firefox 1.0.0 - 1.0.4. Actually it's my workaround. Fabio
Could this bug be fixed in the near firefox 1.0.6? 1.0.5 is still buggy.... Thanks Fabio
Flags: blocking1.8b4?
Flags: blocking1.8b4?
Just tested the URLs in comment #0 with FF 2.0.0.3. Seems to work without any problem.
Assignee: events → nobody
QA Contact: ian → events
works for me - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091222 Minefield/3.7a1pre
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.