Closed Bug 232715 Opened 20 years ago Closed 20 years ago

Serious problems with browser after disk sleep

Categories

(SeaMonkey :: General, defect)

PowerPC
macOS
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: waynegwoods, Assigned: jhpedemonte)

References

Details

(Keywords: fixed-aviary1.0, fixed1.7.5, Whiteboard: see comment 28 for details)

Attachments

(1 file)

User-Agent:       
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040129 Firebird/0.8.0+

If either Seamonkey or Firebird are running when the hard disk is put to sleep,
they have serious functionality problems when the disk wakes again:

Previously open browser windows still function somewhat, although click-and-hold
context menus (e.g. click and hold on a link, if you want to "Open Link in New
Tab") are broken, and the navigation bar fails to update the URL navigating via
a bookmark or other link (curiously, it still seems to update the site icon).

Browser windows opened after the wake are entirely unresponsive to navigation,
except via the home button.

Quitting and restarting the browser fixes the problem (until next time the disk
goes to sleep).

Reproducible: Always
Steps to Reproduce:
1. Go to Apple Menu -> System Preferences -> Energy Saver and set sleep for 1
minute inactivity (not crucial, but obviously makes diagnosis time faster!)
2. Open Firebird or Seamonkey and navigate to a page. Observe that clicking and
holding on a link brings up the regular context menu.
3. Leave the browser window open on the screen, and leave computer inactive
until it goes to sleep. After the monitor goes dark, wait approx. 1 more minute
until you hear the hard disk spin down.
4. Wake the computer up again.
5. Go to the browser window and click and hold on a link. Observe that the
context menu doesn't appear. Navigate to various bookmarks and observe that the
URL bar isn't being updated.
6. Open a new window in the browser. Observe that neither bookmarks or manually
typed URLs will produce any activity.

Actual Results:  
Browser windows fail to function normally.

Expected Results:  
Browser windows should continue to function normally.

I'm running Mac OS X 10.2.8, with all the latest updates. Both browsers use only
the default theme and have no extensions. Bug also occurs with a clean profile.

The bug occurs as recently as 20040129 Firebird/0.8.0+, and at least as far back
as 20031217 Mozilla 1.6b. I haven't tried any earlier builds.
Whiteboard: DUPEME
Partially confirmed in build 2004013005 on Mac OS 10.2.8 9 (old iBook 300 MHz
laptop)

After the laptop went into a light sleep (display off, HD off), click-and-hold
doesn't show the context menu anymore, neighter does ctrl-click. But I'm not
seeing the problems with the url-bar (update ok) or with the bookmarks (menus
pop down), I could navigate just fine. Except for the context-menu, everything
was fine.

But manually putting the laptop to deep sleep (power button or apple-menu),
doesn't show this effect.

It might be related to bug 97640.
Thanks Jo. Just as a clarification.... the bookmarks menu works fine for me too.
It's only context menus that don't. Also, bookmarks themselves, or addresses
manually typed in to the URL bar, only fail to start navigation in new browser
windows that are opened after the sleep/wake. Did you try that with a new window?
Yes, I 

After a light sleep (display & HD off), I opened a new window (with cmd-N or
with the menubar). In that new window the click-and-hold menu didn't work, but
other events (clicking links, typing in fields, clicking backward/forward, ...)
worked ok. And when I went to the locationbar (cmd-L, or click in the bar), I
could type in a new URL, but the Enter key didn't seem to work. The same thing
with choosing a bookmark.

I also noticed that the preference dialog box doesn't want to close anymore (I
wanted to add a go button, to see if that worked).

Note that I wrote before the the ctrl-click didn't produce the context menu
anymore. i have to retract that, b/c I can't reproduce that anymore (ctrl-click
works).

The workaround seems to be very simple : just put your system in deep-sleep
(power-button or apple-menu), and everything will be restored. Even the
preference dialog that was stuck, was gone !

I haven't found any duplicates though.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I have some more info on the origins of this bug. I tested it out on old
Firebird builds.

The last Firebird trunk build that DIDN'T have this problem was 20031030. The
first build to show the bug was 20031103 (this build had broken menus and
scrollbars as well... see bug 224526). In between was a gap of a few days where
Mac builds weren't loading at all, so it's impossible to tell exactly when the
bug was inserted. Kinda looks like a major bug was created before the October 31
build, and either it wasn't 100% fixed, or the fix introduced this problem.

I have also reproduced this bug on a different machine (iMac) running OS X
10.3.2, so it's not just Jaguar. The symptoms observed on that machine were
identical to that seen on my home machine. I have a feeling that sleep is
handled differently on laptops, which could explain why the symptoms reported by
Jo aren't identical to mine. Just guessing.
Then it might be a regression of bug 197863. I wonder if it can be reproduced in
Camino as well (I might try it later tonight).

CC'ing sfraser
*** Bug 234667 has been marked as a duplicate of this bug. ***
With Panther, on a 900MHz iBook... Moz 1.7b shows 'spinning wheel of death'
after waking from sleep. Unsure of whether it's the same bug literally. 

- Firefox 0.8 recovers from sleep gracefully

- Moz 1.6 recovers from sleep gracefully
Flags: blocking1.7+
only drivers should set blocking flags to + or -.
Flags: blocking1.7+ → blocking1.7?
*** Bug 235991 has been marked as a duplicate of this bug. ***
In the above duplicate, Dustin discovered that the bug also kills some
javascript processes (see the timer in his example page in that bug). However it
doesn't seem to kill all javascript, as pages with javascript menus that I
tested still worked.

Couple of other things of note:
- I can only reproduce the sleep bug when my computer is connected to the
internet (I use dial-up).
- Selecting Sleep from the Apple menu won't cause the bug.
I've got the same problems using a 800 Mhz Titanium PowerBook under 10.3.3. when
I close my PBs lid. Navigator windows are still working after waking up the
machine, but get the spinning wheel and "program not responding" in the Dock
when I push the "get new messages" button in Mozilla Mail. 
Severity: major → critical
I notice that this bug doesn't seem to have an assignee yet. As Jo pointed out,
this really does sound like a regression caused by bug 197863. While it might be
a pure coincidence, the other bug also dealt with sleep and the fix was checked
at the same time that this bug began. So perhaps this bug should be assigned to
Simon Fraser as well?

Sorry if I'm appearing impatient. Perhaps stuff is going on behind the scenes.
:) I just noticed that this bug didn't have an assignee yet, and with 1.7
looming I was worried it'd been forgotten and wouldn't be fixed in time. For me,
it's currently the most infuriating Mozilla bug that I encounter, on either
Windows or Mac.
I'll ditto Wayne. I've had to switch to safari since this bug started showing
up... I'm eager to get back to firefox. This bug should be marked as blocking
1.7 imho.
I wonder if this relates to bug 227680.
The dates and nature of the two bugs certainly suggest that they're linked. This
further supports the likelihood of the fix for bug 197863 being the culprit.

Can the fix for bug 227680 be modified to apply here? I know it involved Cocoa,
but perhaps the underlying code changes are still the same.
pink, can you look at this and see if the changes at bug 197863 are responsible
and if the fix at bug 227680 could be made to work for SeaMonkey?
This bug seems particularly vexing for iBook and Powerbook users, since these
tend to sleep a lot.
Flags: blocking1.7? → blocking1.7+
*** Bug 242117 has been marked as a duplicate of this bug. ***
I tested this on my own iBook G4 800 / OSX.3.3 and Mozilla 1.7RC1 recovers from
sleep without problems. Short flash of the spinning wheel, but only for a second
or two (presumably waiting for virtual memory to be returned to solid state
RAM).. I only tested the browser component, though.
I upgraded my iBook from Mozilla 1.6 (final) to 1.7 RC1, and now it hangs
(spinning wheel of death for minutes) very frequently (6x).  I use the browser
and mail components.   I suspect most of my crashes have to do with a change in
network connectivity, e.g. from one 802.11b WiFi station to another; I recall
once Mozilla had hung, I put it to sleep, and woke it on the WiFi it had been
on, and it became responsive again.  Until I can find something reproducible
(I'm trying!), I'm not gonna open a new bug, just throwing out more "it may be
mail or network-related" thoughts for confirmation/contradiction.  (My hangs are
post-1.6, unlike this bug's.)
Mac Mozilla doesn't seem to come with the crash reporter, or at least the times
it's actually crashed (not hung) all I've seen is Apple's crash reporter.  Is
there something I should install?
Some of the problems being described here for Powerbooks ('spinning wheel of
death') are vastly different to the original condition described for desktop
systems.

That doesn't mean they're not resulting from the same bug, but it would be best
to confirm that. If they're not, a new bug should be filed.

Could some of you guys who've reported Powerbook problems under this bug please
check the following:

Please download Firefox builds 20031030 and 20031103. You can get these builds
from: http://archive.mozilla.org/pub/firebird/nightly/

Please confirm that your bug occurs in the latter build, but not the former, and
which symptoms you see (either the browser hanging/freezing/spinning wheel of
death or a simple break down in functionality, like reported for desktop machines).

thanks!
I just tried a Firefox nightly (20040506) on my desktop machine and saw no
problems.  I've also been using Firefox 0.8 and nightlies on my Powerbook,
frequently sleeping with Firefox running.  Haven't noticed any issues there,
either.  This is with OS X 10.3.3.
I haven't seen this bug in a while, either. I'm running a pretty old versin of
Firefox so I'm guessing that a recent mac patch fixed this problem.
Maybe in Panther it did, but it's still broken in Jaguar, 10.2.8, all the latest
updates, using 20040509 Firefox/0.8.0+ default theme, fresh profile.

Just to check, you do have the "put hard disk to sleep" box checked in the
energy saver, and you do wait till you hear it go to sleep before waking the
computer up? 

Either way, I'm afraid the bug still exists.
Flags: blocking1.7+ → blocking1.7-
Still an issue with 1.7 RC3.
Still present in Firefox 0.9 and Mozilla 1.8a2, both on Mac OS X 10.2.8 (Jaguar)

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040614
Firefox/0.9
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a2) Gecko/20040621

At this moment, after a light sleep, behaviour is very erratic :

- click-and-hold contextmenus don't work in either browser
- but ctrl-click contextmenus works though
- The urlbar-popdown works in Mozilla, but doesn't in Firefox. But then again,
the search-popdown works in Firefox, so it's not in every popdown.
- the about dialogbox doens't want to close in Firefox anymore. It works in
Mozilla, but there it's a window.
Flags: blocking1.8a2-
OK, it looks like I can recreate this on my desktop machine, but not my laptop.
 I had a debug build running overnight, and when I woke it up this morning, it
was showing this problem.  I saw the following line in the console:

WARNING: Dropping timer event because thread is dead, file
/Users/pedemonte/builds/fox10/mozilla/xpcom/threads/nsTimerImpl.cpp, line 498

Not sure yet if it is related.
Partially confirmed with Panther 10.3.4 and Seamonkey 1.7 final on an iBook 900MHz

After sleep

 - window-modal dialogs don't register clicks
   - if you end up with a locked window, force-quit is the only option
 - url autocompletion on location bar doesn't work
 - some page navigation shortcuts (space bar for example) don't work
 - throbber is static even when loading a url

Versions
 - Seamonkey 1.8a shows the problem as well. AFAICT, this has been present since
 around 1.6, but there were other more serious problems with IMAP and waking
from sleep too. Make sure you are not being affected by Mail and News bugs on
wakeup, too. 
 - Firefox 0.7 & 0.8 show the same problem. Firefox 0.9 reduces the problem
somewhat: the throbber is still active and quit will handle gracefully windows
locked with window-modal dialogs.

Is there any fix on the nightlies that we should be trying?
No, as far as I know, nobody has fixed anything to do with this bug yet.

Asa asked Mike Pinkerton to look at it in comment 16 (back in April), so it's
likely on his list.
I backed out bug 197863 from my Firefox tree and when I woke up my machine this
morning, it did not show the problems I had seen previously.  So there is
something in the patch from bug 197863 that needs tweeking.  The only other
interesting thing I've seen is the warning from comment #27.
Do the IOKit callbacks get called for disk sleep? Maybe we're turning off timers
on disk sleep, as well as machine sleep.
just odd that camino doesn't have any issues but ff/tbird do.
Maybe becuase Camino isn't relying on Carbon Event-based PLevents?
I see this problem intermittently, which leads me to think it needs an extra
factor to be reproduced 100%. So far, it seems to be a network mount (SMB or NFS). 

The network mount is not dropped, but mozilla (1.7) and firefox (0.9.x) will
misbehave as described. If there is no network mount, moz and firefox are
unaffected. 
What exactly is a network mount? (and SMB or NFS?) :) We established earlier
that you have to be connected to a network (or perhaps specifically dialled in,
but not sure). While dialled in, I can reproduce this every time.
Well, it sounds crazy, but Martin seems to be right.  My computer is always
connected to the internet, but I only see this problem with firefox when I have
an SMB volume mounted.
FWIW, I've seen this bug and to the best of my knowledge, there's never been an
SMB mount on my system.
I wish I knew what an SMB mount was so I could check if I have one ;)

All I have is a simple G4 desktop (HFS+) and I connect to the internet through
dial-up using the standard Mac software and hardware. Sometimes I have CDs
mounted, and sometimes not, but regardless, I can reproduce this problem every
time if I'm dialled in.
Flags: blocking-aviary1.0mac?
Whiteboard: DUPEME → see comment 28 for details
*** Bug 249275 has been marked as a duplicate of this bug. ***
*** Bug 227528 has been marked as a duplicate of this bug. ***
I just posted this in response to a question posed on the duplicate issue 227528
and thought I should post here as well.  I have this happen to me several times
per day.

I'm running 10.3.5 and I am up to date with all patches/updates - just did the
G5 firmware patch this morning.

I have installed the Apple X11 for testing the OpenOffice X11 install.  I also
have several SaMBa mounts which are automounted at boot time.   Unfortunately, I
use them all the time so I can't really remove them and still get my work done
so i can't test if that is it.

This issue is by far the most critical issue for me.  I have recently moved the
Safari browser icon to my Dock simply because of this issue - even though I much
prefer using Firefox.
*** Bug 259161 has been marked as a duplicate of this bug. ***
*** Bug 259913 has been marked as a duplicate of this bug. ***
I can not get this problem to appear on the new Firefox 1.0 Preview Release and
I did see it before.  Fixed?  Can anyone else confirm?
I'm using PR1.0 and it still happens to me quite consistently - 3 or 4 times per
day.
rats!
I've seen this bug without even needing a sleep. It's happened to me within as
little as, say, 30 seconds of opening the browser. This is on iBook G4 800MHz,
10.3.4 and 10.3.5.

You'll see my findings on this in bug #257819.
Just to clarify on my previous post, I'm seeing the issue and I have *no* NFS,
SAMBA or any other network mounts, or even additional mounted volumes such as CDs.

I've seen the issue while connected to a network with a static IP, with a DHCP
IP, and also with the network connection being down (e.g. when I'm on the train.)
(In reply to comment #45)
> I'm using PR1.0 and it still happens to me quite consistently - 3 or 4 times per
> day.

Me too. I would say it's blocking 1.0 on the mac.

When will this be fixed??? Are anyone working to fix it?
(In reply to comment #45)
> I'm using PR1.0 and it still happens to me quite consistently - 3 or 4 times per
> day.

Me too. I would say it's blocking 1.0 on the mac.
I think everyone already realizes what a critical issue this is. However, I
don't think anyone can work out what the cause of this bug is, other than that
it was induced by the fix for bug 197863 by Mike Pinkerton, Simon Fraser, etc.

There was a patch in another bug report that fixed a similar problem in Camino
(attachment 139313 [details] [diff] [review] of bug 227680). That patch made changes to
/mozilla/widget/src/mac/nsToolkitBase.cpp and
/mozilla/widget/src/mac/nsToolkitBase.h . Judging from the directory path,
however, I'm guessing that the changed code is already part of Firefox and
Seamonkey, and therefore won't fix our problem. I could be wrong, though.
*** Bug 233846 has been marked as a duplicate of this bug. ***
Is there anything that we as users can do to help track down what the issue is?
 Is there a way to turn on debug logging or is there an easy way to get an
installation of a debug build?
Attached patch patch — — Splinter Review
So this is what is going on:
1) In the case where user actively selects 'Sleep', the callback function
ToolkitSleepWakeCallback() receives a 'kIOMessageSystemWillSleep' message, and
it posts a 'sleep_notification' notification.  That works fine.
2) In the case where the system goes to sleep after a certain time,
ToolkitSleepWakeCallback() first receives the 'kIOMessageCanSystemSleep'
message, asking Mozilla if it is OK to go to sleep.  Here, it sends a
'sleep_notification' notification, and responds OK.  If the system is actually
going to sleep, it then sends a 'kIOMessageSystemWillSleep' message, to which
we send 'sleep_notification' again.  I don't know if sending this twice in a
row is bad.  However, if we have responded that the system may go to sleep when
receiving 'kIOMessageCanSystemSleep', and then another app cancels the sleep,
then we are in a wierd state where Mozilla has put threads/timers to sleep even
though the system is still running.

This patch makes it so we allow the system to go to sleep if we get
'kIOMessageCanSystemSleep', but don't send out a 'sleep_notification'.	We only
do that when we get the 'kIOMessageSystemWillSleep' message.
Assignee: general → jhpedemonte
Status: NEW → ASSIGNED
Attachment #159620 - Flags: superreview?(sfraser)
Attachment #159620 - Flags: review?(peterv)
Oh, and the reason some of us were seeing this with an SMB mount was that the
SMB mount cancels the system sleep (at least for a while).
Comment on attachment 159620 [details] [diff] [review]
patch

Nice job.
Attachment #159620 - Flags: superreview?(sfraser) → superreview+
Comment on attachment 159620 [details] [diff] [review]
patch

awesome catch, i could never repro so tracking it down seemed unlikely.

r=pink
Attachment #159620 - Flags: review?(peterv) → review+
Comment on attachment 159620 [details] [diff] [review]
patch

Asking for approval across the board.  This is a pretty serious bug for some
people, forcing them to restart the browser and potentially lose data.
Attachment #159620 - Flags: approval1.8a4?
Attachment #159620 - Flags: approval1.7.x?
Attachment #159620 - Flags: approval-aviary?
Flags: blocking-aviary1.0mac?
Comment on attachment 159620 [details] [diff] [review]
patch

a=asa for checkin to 1.8a4. Time is short for a4, so please land there quickly.
Thanks.
Attachment #159620 - Flags: approval1.8a4? → approval1.8a4+
Checked into trunk.
*** Bug 250294 has been marked as a duplicate of this bug. ***
Comment on attachment 159620 [details] [diff] [review]
patch

a=dveditz for 1.7 branch. Please add the fixed1.7.x keyword after checkin
Attachment #159620 - Flags: approval1.7.x? → approval1.7.x+
Whiteboard: see comment 28 for details → [fixed on trunk] see comment 28 for details
Keywords: fixed1.7.x
I don't know if this is the wrong place to ask, since this maybe is a more
general question,? but how long will it take before this patch makes it into
firefox? and when will it make it from the nightly ff builds to the preview?
Confirmed fixed in the lastest nightly trunk build (20040923). I can't believe
it's finally over. ;)

Javier, you are a God!

I'm on a G4 desktop machine running 10.2.8. Hopefully some of our laptop users
can confirm it's fixed for them as well, since some of their symptoms were a bit
different.
Comment on attachment 159620 [details] [diff] [review]
patch

a=asa for aviary checkin.
Attachment #159620 - Flags: approval-aviary? → approval-aviary+
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
Will this fix aboutmagically make it into Thunderbird (which right now has the
same problem) too? Or how does the code base work?
Emil, yes this will make it into all the Gecko based apps.
*** Bug 260993 has been marked as a duplicate of this bug. ***
Hi.

Is there any way I can use bugzilla to determine if this was included in the
latest build (0.10.1)?

pete.

ps.  Thanks Javier on an excellent bit of detective work.
 > Is there any way I can use bugzilla to determine if this was included in the
> latest build (0.10.1)?
> 
> pete.

I'm still experiencing this bug in Firefox 0.10.1 using Mac OS 10.3.5, fully
updated, on a Powerbook G4 Aluminum. The fix sounds right to me so I'm guessing
it has not made it into Firefox yet.

This is one of the most annoying browser problems I've ever encountered so I am
VERY glad to see help on the way.

Is there a patch we can apply without waiting for a new release? I can't find
nightly builds of the Firefox 0.10 pre-release on the Mozilla site - must be
there somewhere - maybe somebody can clue us in.
Does that mean this bug isn't fixed on the Aviary branch yet? It has the
keywords "fixed-aviary1.0, fixed1.7.x", and it's resolved as fixed. If not, we
should reopen it.
This was not included in Firefox 0.10.1 (that was just a security fix), but it
will be in the next official version.  In the meantime, you can use one of the
Firefox nightlies
(http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-0.9/Firefox-mac.dmg.gz)
I'm on a Powerbook G4 Aluminum running 10.3.5. Downloaded the 10/11 Firefox
nightly build at 10 AM today and have used it all day, through several sleep
cycles, without experiencing either the sheet freeze problem or the
click-and-hold context menu problem. Confirming bug fixed on my laptop.

Javier, you are magnificent! 

Status: RESOLVED → VERIFIED
Whiteboard: [fixed on trunk] see comment 28 for details → see comment 28 for details
*** Bug 263955 has been marked as a duplicate of this bug. ***
*** Bug 265562 has been marked as a duplicate of this bug. ***
*** Bug 238574 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
*** Bug 275763 has been marked as a duplicate of this bug. ***
*** Bug 275747 has been marked as a duplicate of this bug. ***
I have been working with v1 for the past week or so and have had absolutely no
problems. 

Thank you everyone for fixing this bug and the great work. I feel like I have
gotten more than monies worth in donating to Mozilla/Firefox!

cheers
dn
*** Bug 268325 has been marked as a duplicate of this bug. ***
304298 and 325188 would tend to suggest that this bug isnt fixed entirely.
You need to log in before you can comment on or make changes to this bug.