Onload events fail sometimes on first load and almost always after successive frameset loads. Build 2000110304 on Win95 This bug kills applications that are well designed, event driven, timer-less. This problem may appear hard-to-reproduce and intermittent on a slow internet. However, the supplied test case is exact, unforgiving and non-negociable. This will remain a disaster if not resolved. I would recommend to not release a browser where onload events are broken, because they belong to a browser as much as a distributor and spark plugs to a car engine. If not solved, these problems will create really bad memories with developers who know what they are doing and will probably more than offset the otherwise excellent features of this browser. Others in this critical category: http://bugzilla.mozilla.org/show_bug.cgi?id=57636 http://bugzilla.mozilla.org/show_bug.cgi?id=35253 http://bugzilla.mozilla.org/show_bug.cgi?id=49165
New condition found: The bug is probably cache related. Can be reproduced with: Edit|Preferences|Category Advanced|Cache|Compare...Every time I view the page: checked.
This bug is absolutely mission critical because an e-commerce application of one of our clients will no longer run under Netscape 6 with this error. For the company having this application Netscape 6 means close of business. Currently the site refers to Netscape as preferred browser. It is vital that I receive confirmation that this bug is fixed before the bublic release of Netscape 6, otherwise the only solution is to recommed Microsoft Internet Explorer. It appears appropriate to treat this bug with the "blocker" severity status and highest priority because developers must be able to assume that basic functions of the browser (i.e. not deprecated and replaced by alternatives) do not disappear in later releases. If this is not the case then Netscape will not be a browser for professionals. I am looking forward to your urgent response.
Confirming this bug on the strength of the reporter's testimony and testcases. It's not on the radar yet because UNCONFIRMED. /be
Status: UNCONFIRMED → NEW
Ever confirmed: true
Per email... I'll add the rtm nomination keyword for N6, but the train is really pretty far out of the station now, and I don't know that we'll be able to do much.
Reporter, I've been testing out the supplied testcase today and I'm sad in saying that I don't see a problem, I've had your files stored locally on my harddisk, I had them on a local webserver, I had them out on a server on the other side of the planet, I've tested different cache settings and I never seen any onload events not fire. The only weird thing I see is that session history fools the page a bit when you reload (or navigate back or forward to) set1.htm, when reloading set1.htm I get: - "Waiting for level 1 onload event" when we load set1.htm from session history - "Waiting for level 2 onload event" since set2.htm is loaded by session history - "Level 2 onload event fired OK" since set2.htm finished loading, this load was initiated by session history. - "Level 1 onload event fired OK", now this event does a XX.location='set2.htm' that will load set2.htm into the XX frame once more, so I get... - "Waiting for level 2 onload event" since set2.htm is now loaded the onload handler in set1.htm - "Level 2 onload event fired OK" since set2.htm finished loading again. That's the only weird and arguably incorrect (but Netscape 4.x works the same way) behavior I could trigger with the supplied testcase and that weirdness can be worked around in the onload handler in set1.htm by checking if the location is already set to '.../set2.htm' before setting the location of the XX frame... If there's really a problem here we need to get more info on how to reproduce this problem, in all my tests the onload events do seem to fire just as expected... Oh, did you use a build that was off the mozilla trunk or the Netscape branch, I did most of my tests on a build off the Netscape branch (which is what'll chip as Netscape 6) but I did try in a trunk build too and it seemd to work just fine there too for me. Where did you download your build from?
Johnny, many thanks for your test. I downoaded Mozilla directly from the build bar. That link is now: ftp://ftp.mozilla.org/pub/mozilla/nightly/2000-11-06-06-Mtrunk/mozilla-win32-talkback.zip but I have not recorded what it was when I downloaded the build that has the error. Please supply a download and I will re-test.
History was not involved in my test (thanks for mentioning this). I am aware of the issue and the application has its own history module to work around this. In the test case I never used any controls except the loaction bar with enter key and the enter key on the alert boxes. The test case was reduced from the application in ca. 25 steps where the problemconsistently occurred in each step. To get the error, however, I must execute the test more than once. I have noticed a pattern where on run 1, all is fine, on run 2 level 2 events fail and on run 3 level 1 events fail.
Pleases try to reproduce this with ftp://ftp.mozilla.org/pub/mozilla/nightly/2000-11-07-09-MN6/mozilla-win32-talkback.zip I just loaded your testcasae 10+ times in a row without seeing any problems with a build that should be more or less equal to the one at the above location, after that I browsed to some other pages and then loaded your testcase 5 more times and still no problems... This could be a regression on the mozilla trunk that does not happen with a Netscape 6 build.
Johnny, many thanks again for your test. The good news is that I cannot reproduce the error with the latest build 20001107 from mozilla-win32-talkback.zip I think it is fair to assume that we do not have a hidden problem with reproducability. The test case has done the job and the shipping Netscape version will be OK wrt this bug after passing it. I suggest to add this test case to your test suite. No bad news :). Closing bug.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
It's back in build 2000111704.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Reporter do you still see this in the latest builds?
Still failing in build 2000122204
Worksforme in todays build, please reopen if you still see this problem.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → WORKSFORME
Verified with 2001-020608.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.