59164 - onLoad events broken in framesets

Status: VERIFIED WORKSFORME

(Core :: DOM: Core & HTML, defect, P3)

Description

[bht237]

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

Comment 1

[bht237]

Attachment: Collection of test files (zip archive)

Comment 2

[bht237]

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.

Comment 3

[bht237]

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.

Comment 4

[Brendan Eich [:brendan]]

Confirming this bug on the strength of the reporter's testimony and 
testcases.  It's not on the radar yet because UNCONFIRMED.

/be

Comment 5

[Jim Roskind]

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.

Comment 6

[Johnny Stenback (:jst)]

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?

Comment 7

[bht237]

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.

Comment 8

[bht237]

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.

Comment 9

[Johnny Stenback (:jst)]

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.

Comment 10

[bht237]

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.

Comment 11

[bht237]

It's back in build 2000111704.

Comment 12

[Fabian Guisset]

Reporter do you still see this in the latest builds?

Comment 13

[bht237]

Still failing in build 2000122204

Comment 14

[Johnny Stenback (:jst)]

Worksforme in todays build, please reopen if you still see this problem.

Comment 15

[Prashant Desale]

Verified with 2001-020608.