103559 - MSDN DHTML Reference w/ JS enabled crashes browsers within a few pages

Status: VERIFIED DUPLICATE of bug 98306

(SeaMonkey :: General, defect)

Description

[Alex Vincent [:WeirdAl]]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20010913

I just sent in a Talkback notice about this -- don't know who receives those,
but somebody in QA should be able to find it.

Ever since MSDN redid their DHTML Reference frameset for their IE6 rollout, I
have seen dozens of crashes in Nav6.x, IE5.x, IE6, and Mozilla 0.9.x.

By disabling JavaScript on Nav6.1, I have been able to browse the reference with
no problem.  At the same time, the leftside frame has curiously stopped updating
itself.

The leftside frame is totally new to the layout MSDN is using.  This leads me to
suspect the leftside frame is doing something in JavaScript.  

The biggest hits come when I click on a link in the right-side frame, the
content frame.  That forces a reload of both frames.  Load time goes up
significantly -- sometimes to over a minute or more.  I have DSL modems on these
machines.  CPU usage skyrockets, pegged out at 100% for very long times.

Very often it'll crash the browser which tries to look at it.

What makes this bug interesting to me is that when I disable JavaScript, I have
no problems whatsoever browsing the Reference.  It comes up quickly, loads fine,
works like a charm.  Which is ironic, because the reference covers a lot of DOM
issues, for which having JavaScript enabled is pretty important.

I'm not writing this bug to say Microsoft should fix their layout (although they
should).  But the crashes occur only when JavaScript is enabled.  Something in
their site, which calls on JavaScript or JScript routines, results in a crash. 
Sometimes it takes browsing around several pages at random.  

Reproducible: Always
Steps to Reproduce:
1.  Visit the above URL with JavaScript enabled.
2.  Browse around a few of the links -- follow one link to another, then
another, etc. in a chain.  More easily reproducible when you click in the
content frame for links, as it forces a reload of both the menu frame to the
left and the content frame.

Actual Results:  Browser crashes and/or experiences massive slowdowns, and
Talkback notification comes up.

Expected Results:  Browser should not crash.  If it finds something too big for
it to swallow, please throw up an alert.

I have seen this problem on three separate machines, and on IE and Netscape
browsers in addition to the Mozilla 0.9.4 milestone.  (I did not report it
before now because I suspected the other two machines, not meeting minimum
requirements, were at fault.  This machine meets minimums and still crashes.)

I'm not sure what component this falls under.

Comment 1

[Matthias Versen [:Matti]]

Reporter: 
Can you run : <Install-Dir>\mozilla\components\talkback.exe and poste the
Talkback ID in this bug ?

Comment 2

[Alex Vincent [:WeirdAl]]

Incident #TB36380109K.  HTH

Comment 3

[Matthias Versen [:Matti]]

CC may personal Talkback bot : #TB36380109K

Comment 4

[Olivier Cahagne]

wfm using build 2001100610 on Win2k.

Reporter, can you try with a newer build and report if the bug still occurs.
Build available here:
http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-talkback.zip

Comment 5

[Alex Vincent [:WeirdAl]]

Sorry, wrong URI.  (The frameset didn't appear.)

Downloading the nightly now.

Comment 6

[Alex Vincent [:WeirdAl]]

Ok, I'm trying (and failing) to generate a crash in the nightly.  Could be this 
bug has been fixed after 0.9.4 and I wasn't aware of it.

After many many page views, nightly froze on me when I tried to view-source of 
the left frame.  Had to CTRL+ALT+DEL to get out of it.

Restarted nightly.  Still no crash.

Something very unusual is going on here.  MSDN has a script to put itself into 
a frameset automatically, via its PreInit() function.  Somehow, the nightly, 
when you open one of the links in a new window, isn't changing the URL like it 
should.  The leftside frame isn't changing as it normally does.

Comment 7

[Alex Vincent [:WeirdAl]]

Ok, I'm stumped.  I have no testcase for this.  About all I can figure out is
that changing document.URL is not affecting what page the browser is on.  For
all I know, that's correct behavior.  I'm tempted to mark this bug WORKSFORME
because now I can't reproduce the crash even in Moz0.9.4.

I regularly had crashes on this site, to the point where it was ridiculous. 
Now, it's disappeared.

Comment 8

[John Morrison]

this was fixed (crash in parseatom on a bogus regex).

*** This bug has been marked as a duplicate of 98306 ***

Comment 9

[Phil Schwartau]

Verified Duplicate - 

Having no problems or crashes at this site now -