Page loads never complete on




18 years ago
17 years ago


(Reporter: aboyer, Assigned: neeti)


Mac System 9.x

Firefox Tracking Flags

(Not tracked)





18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.1+) Gecko/20010628
BuildID:    20010802, I think (away from machine - see below)

Visiting results in a fully-drawn page but the Mozilla throbber
and progress bar continue to run.  Subsequent connections to sunspot (i.e.,
trying to visit a link on the page) result in no data being sent to Open
Transport (OTSessionWatcher).  Hopping onto another site allows you to continue
browsing.  Sub-pages work correctly if they are your first step onto the site.

Reproducible: Always
Steps to Reproduce:
2.Click on a link
3.Wait forever

Actual Results:  Mozilla sat attempting to visit the selected link.

Expected Results:  The linked-to page should have been retrieved and displayed.

I don't know what is causing the problem, but it does not happen at work on a
WinNT PC running 2001062804 or on the same problem machine running OSX (0.9.3).

This has been happening for a long time, since at least 0.9.

Comment 1

18 years ago
Works for me under Mac/2001080214 (0.9.3).

Reporter, try the usual things; new profile, delete Mozilla Registry in Preferences.

Comment 2

18 years ago
a new profile would be interesting b/c it would isolate your current cache

Comment 3

18 years ago
Last night I downloaded the 0.9.3 talkback build, deleted the preferences, and
deleted my entire profile.  The problem appeared on my first access to

Tonight I will attempt to capture the whole transaction with OTSessionWatcher.

Comment 4

18 years ago
I've encountered a problem recently where if a page contains a SCRIPT SRC URI that's 
momentarily inaccessible for some reason, page display stalls, and will not complete until 
the SCRIPT loads. If the SCRIPT never loads, the page never displays. That could be what's 
happening here, as there is one such SCRIPT SRC on the page, though it's on the same 

Comment 5

18 years ago
The bug I refer to in the previous comment is bug 93955.

Comment 6

18 years ago
What's your network configuration?

Comment 7

18 years ago
Reporter, are you still experiencing this problem? Did you have any success using 

Comment 8

18 years ago
I can still reproduce the problem consistently.
My two machines both exhibit the symptom.  Using OTSessionWatcher 2.0 (the
latest I could find), Mozilla locks up hard.  Note: There is no obvious crash
when not running OTSessionWatcher.

The two machines:
Quicksilver G4/733, OS 9.2.1
G3-Upgraded PowerCenter Pro, OS 9.1

Comment 9

18 years ago
aboyer, is TalkBack running after these crashes? Please note that 0.9.3 as installed doesn't 
run it by default. There's a bug in the supplied Component Registry that prevent it from 
running. You have to delete that file, then rerun Mozilla to get TB working again.

Once you do, paste some TB IDs to this bug.

Comment 10

17 years ago
Reporter, please address my questions. Also, please retest using 0.9.4.

Comment 11

17 years ago
In my tests this evening, neither the latest nightly build nor the latest
talkback build had any trouble with

The nightly build - without talkback support, at least that I could find -
continued to crash on when using OTSessionWatcher.  It is not just
Mozilla that crashes; the whole system locks up.  The 0.9.4 milestone build did
not crash on when OTSessionWatcher was running, so TalkBack never ran.

The network configuration is a Quicksilver 733 connected via an SMC Barricade
router to a Telocity DSL modem.
I am tempted to conclude that the issue might not be present in 0.9.4. 
Tomorrow, schedule permitting, I will try to dig up a copy of 0.9.3 and see if I
can convince TalkBack to run.

Comment 12

17 years ago
Reporter, just to be sure, try booting with only "Mac OS 9 All" extension set enabled and 
see if it still happens.

Comment 13

17 years ago
Reporter, can you still reproduce this using 0.9.5?

Comment 14

17 years ago
Mozilla version 0.9.5 does not exhibit the problem.

In fact, it seems to work very well.

Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.