Reproducible mozilla crash on W95 build 1999121712




19 years ago
18 years ago


(Reporter: Stephen Anderson, Assigned: vidur (gone))



Windows 95

Firefox Tracking Flags

(Not tracked)





19 years ago
Okay, this one is complicated to reproduce so follow these steps exactly.
Running W95 build 1999121712.

Shut down any running mozillas.
Launch a fresh mozilla
Goto the URL listed,
WAIT for the page to completely load.
Click on "Florida man faces federal charges for Columbine Internet Threat"
WAIT for the second page to completely load
Click on the back button
QUICKLY BEFORE the first page is finished loading:
     double-click in the addr bar to highlight the entire entry and type in a
URL (eg
Hit enter to go to the URL you just typed.  *CRASH*

This was a hard bug for me to reproduce, but once I got the hang of it I can
get it to crash 4/5 times.  Their seems to be a couple keys to getting the
crash to rear its head.  1)  The address you type must be someplace you have
not gone in your current session (hence I say start a fresh mozilla).  If I do
this on a mozilla that has already been to slashdot, it will not crash if
that's the address I use.  A DNS thing?  2)  The crash works best if you hit
enter for the URL you typed at the point in page rendering when it has rendered
the CNN headings and sidebar links, but not the text yet.  Not too hard, but
takes a time or two practice.  If it is a layout timing thing I should tell you
I'm using:

56K modem
C6-200 running W95 OSR2
user_pref("content.notify.backoffcount", 3);
user_pref("content.notify.interval", 4000);
user_pref("content.notify.ontimer", true);

Now I think this is going to be a real bear to boil down to a "simple"
testcase.  I'll try, but no garuntees.

Comment 1

19 years ago
This bug appears to be an artifact of some part of mozilla's processing and
probably not related to the HTML content of the pages.  I say this because I
was able to reproduce this bug by:

Starting a fresh mozilla
going to
following a link to a story about the dude caught with bomb stuff
reading the article and then hitting the back button
While loading, entering the url and hitting enter.

It would be a high coincidence if both CNN and abcnews' webpages had the same
strange HTML to prompt this bug.  I will be trying to isolate any timing issues
that may/may not be involved instead of trimming the HTML down.

Comment 2

19 years ago
Slashdot to a "Read More" link back then crashes as well.

The only key issues I can find here seem that the "first" page needs to be long
(take a while to load) and that the sooner you enter the URL after going back
to the first page the better the chances of causing the crash.  For this last
case I tried doing it but letting the page render about 50% (seat of the pants
est.) and then entered the URL - no crash.  Hmm... I wonder if it has to do
with number of page reflows....

Comment 3

19 years ago
Although significantly more difficult to do so, I was able to reproduce the
crash with:
user_pref("content.notify.ontimer", false);

With notify.ontimer turned off, I believe mozilla is spawning a lot more page
reflows and it's harder for me to get the URL entered in the first X reflows.
To test this gut instinct, I'm turning timed reflows back on but making the
time between reflows much longer.  Hopefully that will yield more insight.

Comment 4

19 years ago
Twiddling with the timed reflow preferences further proved inconclusive to me.
I think I've taken this bug description as far as I can.  It needs some stack
traces or debug output I think.

Comment 5

19 years ago
I've found that my steps to reproduce need not be so strict in a few areas.
Basically you start with a fresh browser.  Then you go to a long page (eg. then you go somewhere else (follow a link) then once most of the
second page has loaded, you use the back button.  Then before the first page
loads very much you go somewhere else.  I thought you had to hand type URLs,
and stuff but it seems it's easier to reproduce than I thought.  I went to
CNN's main page, followed a link.  Read about the democratic debate.  Hit back,
then pretty soon (before it loaded much of the main page) clicked on one of
their feature links (food with feelings).  Sure enough, it crashed.

I hope we can nail this one down because I'm beginning to think it is
responsible for 90% of all mozilla crashes that I experience.

Comment 6

19 years ago
Yep, stephena. I can reproduce this 1999121708 WinNT.

Comment 7

19 years ago
changing assignment from to

Comment 8

19 years ago
[Correcting assignation from "" to "".]

Comment 9

19 years ago
This bug appears to have slipped under the rug.  While more difficult to
reproduce, I was still able to reproduce it under build 2000010408.  I am
reassigning to "owner of selected component" hoping that it will fall to
somebody other than nobody.

Comment 10

18 years ago
This bug causes at least five page faults per day on me.  It was filed over a
month ago.  Is there a chance it could at least get assigned to somebody?


18 years ago
Assignee: nobody → gagan
Component: Browser-General → Networking
QA Contact: nobody → tever

Comment 11

18 years ago
Updating QA contact.

Comment 12

18 years ago
reflow related?
Assignee: gagan → troy
Component: Networking → Layout
QA Contact: tever → petersen

Comment 13

18 years ago
Re-assigning to Vidur, because it's content sink related
Assignee: troy → vidur

Comment 14

18 years ago
Sorry this got moved around so much. I can't seem to recreate it on the 
1/26/2000 build using either the URL bar typing or link clicking schemes 
described., could you confirm that it still exists? If it 
still does for you, it's probably timing related - something that it will make 
it oh so much fun to debug.

Comment 15

18 years ago
Well... I'm pretty sure it still happens.  However, I just downloaded today's 
nightly build and got "The XPCOM.DLL file is linked to missing export 
KERNEL32.DLL:GetFileAttributesExA.  So... doesn't look like I'll be getting any 
testing done on this version.  I report back tomorrow assuming tomorrows build 
actually starts.

Comment 16

18 years ago
stephena: the 'XPCOM ...' problem is bug #25028. Maybe fixed in tomorrow's 
builds (but maybe a little longer) -- see bug for details.

vidur: I have dup'd this with builds after 12/18 (perhaps as late as 01/10), 
but I had tried with 01/21 and couldn't do it. But, yes, my sense of the crash 
is that it is timing related (oodles of fun -- although, I think that this has
more to do with either necko or "history" -- but that is purely my guess).

Comment 17

18 years ago
I just got done trying to reproduce this bug in M13.  I was not able to.
However, if at all possible, I would like to withold resolving this bug for a
period of time.  In my tests I found that mozilla has a new bug which may be
masking this crash.  I found that when you click on a link while a page is
reflowing (from a back operation) mozilla incorrectly registers the new link to
load as the present location.  The crash I originally reported was most easily
reproduced by clicking on a link during the reflow after a back.  It may be that
the crash is still there but not showing up since the link click is not
registering as a new link.  One of the odd pecularities of the original bug was
that you had to link to somewhere you had not been before (in that session).  So
it is quite possible that this mishandling of the link click is masking this
bug.  I'll go try and find the bug associated with this mishandling or file a
new one.

Comment 18

18 years ago
Adding "crash" keyword to all known open crasher bugs.
Keywords: crash

Comment 19

18 years ago
I'm still not able to reproduce this. There's been enough change to the webshell 
loading process that I don't doubt that the original bug has been fixed (and 
possibly replaced with a new set :-))., can you confirm that 
this no longer appears on a recent build. Thanks.

Comment 20

18 years ago
Yes, I agree.  I am unable to reproduce this bug. While the other page loading
link click is still broken, I will concentrate on seeing that get fixed.  If
this bug should become a problem once that is fixed I will file a new bug and
reference this one.  In the meantime, I guess it's only fair to call this fixed.
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 21

18 years ago
Fixed in the Feb 29th build.

You need to log in before you can comment on or make changes to this bug.