Opening the page will jam or crash mozilla.



17 years ago
14 years ago


(Reporter: hingo, Assigned: Matti)


Windows 98

Firefox Tracking Flags

(Not tracked)





17 years ago
... at least most of the time.

I'm not sure whether this is a problem in showing the page or something
happening with the network transfer.

I'll attach a recent copy of the page too.

Comment 1

17 years ago
wow, what a fascist policy on attachment size! Ok, here is a copy of the page:

Comment 2

17 years ago
Again, my exact build is
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530

Comment 3

17 years ago
WFM on Mozilla 1.0 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530
yesterday's 20020701 Trunk build for windows.

Comment 4

17 years ago
wfm with win2k build 20020630..

Comment 5

17 years ago
with linux build 20020701, Mozilla appeared did appear to hang duing page load.
 I fired up debug build to get a stacktrace and it did freeze for a bit, but
eventually rendered the page ok.  Binary build took > 2 minutes to load.

Henrik: if you wait long enough, does the page eventually load?

Comment 6

17 years ago
In fact, yes it did. Approx 20 secs when loading from hard disk. (I could have
sworn I waited at least that long yesterday.)

I guess when you add a random network hiccup to that, it makes it look like
nothing is happening.

I also tried at work, same 1.0 build on win2000, and it also worked.

So, false alarm, calm down. Whether you want to tune something based on this or
just forget it is up to you.

Comment 7

17 years ago
... oh, but now that I think of it, once it actually crashed all browser
windows. That one I haven't been able to repeat.

Comment 8

17 years ago
did you get a talkback ID for the crash?

Comment 9

17 years ago
No, everything just disappeared.

Comment 10

17 years ago
WFM - Trunk build 2002081304 - WinXP.

Comment 11

16 years ago
This is oviously a VERY long page, and I suspect that layout is doing
incremental reflows much too often for the amount of data on the page, and
because layout is not interruptable, the UI stops responding (See Bug 51202, Bug
67752)... the crash was probably caused by an out-of-memory condition or some
similar anomaly.  I am going to mark this bug WONTFIX because there are already
bugs files on the underlying issues.  If you continue to crash on this page and
can provide a talkback ID or a stacktrace, feel free to re-open this bug...
perhaps there is another problem lurking that can be fixed.
Last Resolved: 16 years ago
Resolution: --- → WONTFIX
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.