Closed Bug 97640 Opened 24 years ago Closed 23 years ago

Conn: OS X after sleeping: click on link -> page won't load

Categories

(Core :: Networking, defect, P3)

PowerPC
macOS
defect

Tracking

()

VERIFIED WORKSFORME
mozilla1.0

People

(Reporter: bugzilla, Assigned: gordon)

Details

(Keywords: platform-parity, testcase)

i've been seeing this off and on for the past couple of weeks. if anyone has further info/suggestions on how this may be narrowed down, that'd be great. on my Mac OS 10.0.4 box, i've noticed that sometimes after i click a link, the page won't load. the throbber and progress meter keep spinning, but the page doesn't load --whether it's be a link i've accessed before or a unvisited one. i wonder if this might have to do with the machine being asleep for a long period of time? here's the scenario for the last time i noticed this: 1. yesterday i went to http://www.google.com/ 2. entered a search string, eg, 'jardin mecanisme' [without the quotes] then clicked the Google Search button. 3. clicked the first link in the results. 4. viewed that page for few seconds, then hit cmd+back arrow to get back to the Google query results page. 5. left the machine untouched overnight. 6. woke the machine up [moved/clicked mouse and tapped spacebar]. 7. tried clicking the first link as well as an unvisted link in the Google query results page. results: throbber and progress meter spun and spun... anyone else see this? could it be related to either bug 71718 or bug 95851?
Keywords: pp
another note: i tried repeating the above recipe with one difference: the machine had been asleep for less than an hour. in that case, i couldn't repro the problem.
Probably related to bug 71718.
what if you manually put the machine to sleep?
cannot repro after manually putting mac to sleep [and letting it sit for a few min].
a bit more info: i'm now seeing this, and the machine has been asleep [not manually] for about 1-2hrs. also: the throbber is animating rather slowly --and the status bar says "Document: Done (xx.xxx secs)" even though the progress meter is still animating. i'll see for how long this'll last [been about a couple min so far...].
okay, i gave up after about 10min after clicking a link. the link, btw, was one i had visited before. perhaps that link isn't in the cache? fwiw, my caching pref for this profile is set to "automatically" compare the page in the cache to the page on the network. i tried a new window [File > New Navigator Window], and it took nearly 3min to load [uses the home page i had set in prefs]. i'm now trying the URL bar: entering www.nytimes.com [which i haven't visited before with this profile]. again the throbber is slowly animating and the progress meter spins. however, the status bar msg doesn't display "Document: Done", it displays "Resolving host http://www.madsci.org" the site [but not the complete url] of the current/unchanging page. i'll wait another 10min or so...then try another test: bookmark access.
i hit the stop button after 10min with the URL bar test to www.nytimes.com. bookmark access: i selected a bookmark for Yahoo [which i haven't visited in the current session]. no page load after about 10min there as well. differences: the throbber seems to be animating a bit more quickly; but the progress meter still spins. the status bar this time has "Connecting to www.nytimes.com", oddly enough. [just clicked stop again.] tested fwd/back [cmd+right/left arrows], and that works fine. so session history seems fine --except that opening a new window had taken a while [3min as previously mentioned]. so, quitting and restarting the app is the only workaround i can think of at the moment for this... and, drat, i just crashed when i quit that last session. annoyingly, CrashReporter didn't manage to append it to crash.log.
well, phooey. i ran into a similar issue *without the machine having gone to sleep*: i had recently relaunched the netscape build, then selected a bookmark to load. after about 2min of spinning, that page wouldn't load --i got an alert dialog: "The operation timed out when attempting to connect to www.madsci.org." different or the same bug? the funny thing is, my homepage for that profile is http://www.madsci.org/~lynn/juju/lips/lips.html --but the bookmarked url which failed to load is at http://www.madsci.org/~lynn/juju/jardin.html. [which happily load on win32 and linux bits. more strangeness: i then selected another bookmark, to Yahoo [http://www.yahoo.com/], which loaded fine. hm hm hm...
sairuh - to help troubleshoot further, can you email qa and perhaps post to qa newsgroup to see if others have the same problem. Maybe more clues will help.
I have not been able to reproduce it. Lets see if it is isolated to a couple machines.
Steve, Simon, Patrick, have any of you seen behavior like this?
I haven't seen it but my Mac isn't set to go into deep sleep as I leave ircle running on it. One guess I'd make is related to machines with DHCP vs. static IP addresses. As I recall there is no notifier under X that your connection went away as with OT (even though we're still using the OT APIs) so if the Mac lost its DHCP lease while asleep you might trigger this. You'd think we'd timeout on this but maybe not
Target Milestone: --- → mozilla0.9.6
hm, interestingly, my mac os x box has a static IP address. i had turned off deep sleeping [system, display, hard disk] several weeks ago...and i haven't encountered this problem recently.
Moving to necko stability milestone 0.9.8.
Target Milestone: mozilla0.9.6 → mozilla0.9.8
I'm getting the same problem right now on 2002010308 on MX OS X. This it the first time I've seen it on any Mozilla. Quitting and restarting did not fix the problem for me, nor did sleep seem to have been the original cause -- I left my computer on and disconnected all day with Mozilla running, but not asleep. Oddly, I seem to have better luck when Internet Explorer is also surfing other sites in the background.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
not critical enough for nsbeta1 cuz of low visibility.
Keywords: nsbeta1-
Priority: -- → P3
Target Milestone: mozilla0.9.9 → mozilla1.0
Say what? Links not working after my laptop goes to sleep is "low visibility"?
Of course "low visibility" might better be said as "has a low frequency/chance of occurance" (see my previous comment on losing the DHCP lease while asleep) in which case I'd agree.
'low visibility' means we don't get to see you that often :-P (so how exactly do you expect us to see your laptop!) j/k On a serious note Gordon believes that this may be related to one of his other bugs that he is fixing. nsbeta1- just means it's not critically a stop ship for machV. If you strongly feel otherwise then let's change it to plus. otherwise I'd let the stars and gordon work this out... :)
Actually I've never seen this occur on my laptop which is why I added the 2nd comment where I agreed this is nsbeta1-
So, is the basic testcase: put mozilla to sleep for 10+ minutes, then observe very slow performance? Possible causes include DHCP. I've been looking at the connect/disconnect aspects of sleep, networking and Mac OS X. I only go to sleep for a couple seconds, and Mozilla and Chimera work as expected. I'll try to spend more time on the longer sleep question today.
Summary: OS X after sleeping: click on link -> page won't load → Conn: OS X after sleeping: click on link -> page won't load
RESOLVED/WFM: We have not received new dupes, which is a good sign. I have not seen this problem in Chimera 0.4 or Mozilla 1.0x & 1.1. I have tested both an iBook w/ PPPoE DSL and a G4 on the corporate LAN. I also talked w/ senior tech support contact at Apple, and he said that there is only one kind of sleep (there used to be more?!), so if it passes on these two disparate platforms, we are in good shape.
sarah: can you VERIFY?
Status: NEW → RESOLVED
Closed: 23 years ago
Keywords: verifyme
Resolution: --- → WORKSFORME
VERIFIED: Mac OS X 10.2, Mozilla 1.2.1. This is a testcase now, so I'll be checking regularly.
Status: RESOLVED → VERIFIED
Keywords: verifymetestcase
Could this checkin have caused bug 232715 ?
I doubt it. For one thing, there is no patch in this bug :)
You need to log in before you can comment on or make changes to this bug.