Closed Bug 93937 Opened 23 years ago Closed 23 years ago

Page loads never complete on sunspot.net

Categories

(Core :: Networking: HTTP, defect)

PowerPC
Mac System 9.x
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: aboyer, Assigned: neeti)

References

()

Details

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 www.sunspot.net 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:
1.Visit http://www.sunspot.net
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.
Works for me under Mac/2001080214 (0.9.3).

Reporter, try the usual things; new profile, delete Mozilla Registry in Preferences.
a new profile would be interesting b/c it would isolate your current cache
directory.
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 Sunspot.net.

Tonight I will attempt to capture the whole transaction with OTSessionWatcher.
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 
server.
The bug I refer to in the previous comment is bug 93955.
What's your network configuration?
Reporter, are you still experiencing this problem? Did you have any success using 
OTSessionWatcher?
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
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.
Reporter, please address my questions. Also, please retest using 0.9.4.
In my tests this evening, neither the latest nightly build nor the latest
talkback build had any trouble with sunspot.net.

The nightly build - without talkback support, at least that I could find -
continued to crash on sunspot.net 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 sunspot.net 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.
Reporter, just to be sure, try booting with only "Mac OS 9 All" extension set enabled and 
see if it still happens.
Reporter, can you still reproduce this using 0.9.5?
Mozilla version 0.9.5 does not exhibit the problem.

In fact, it seems to work very well.

-Andrew
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.