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
Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.