Closed Bug 428565 Opened 17 years ago Closed 12 years ago

Firefox 3.X delays/prevents machine sleep on Mac OS X

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: todavemartin, Unassigned)

References

Details

(Whiteboard: qawanted)

Attachments

(2 files)

Activity sample
3.66 KB, text/plain
Details
A screen grab showing sleep settings, extension listing, and 'about' dialogs
475.70 KB, image/jpeg
Details
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_2; en-us) AppleWebKit/525.13 (KHTML, like Gecko) Version/3.1 Safari/525.13 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5 Hi, It seems FF prevents "automatic" sleep on Mac OSX Leopard. Sleep works fine when shutting the lid on my Macbook Pro or forcing sleep using the apple menu. Looking at activity monitor it looks like FF writes to disk at least once per minute. While the display will go to sleep this disk activity prevents automatic deep sleep of the system. To replicate set auto sleep to 1 min. in system preferences, open up FF 3b5 and surf to apple.com. You'll note the display sleep but not the system sleep. That is, the light does not pulsate and the system fans continue to run. Safari does not have this issue with the same page loaded. thanks for any assistance. Reproducible: Always Steps to Reproduce: 1.set auto sleep to 1min. 2. start FF and load any website (e.g. apple.com) 3. Display will sleep but system won't deep sleep.
Severity: normal → major
Same result here with Firefox 3 RC1 on OS X 10.5 on a Mac Pro.
Still happening with RC2, on both a MacBook Pro and Mac Pro, both running 10.5.3. Interestingly FF does not prevent sleep if no windows are open.
Still happens on 3.0 - pretty annoying, especially when you're on a laptop and you're used to woking power management. system is leopard 10.5.3
Same result with Firefox 3 on a mac mini, PowerPC G4, running 10.4.11.
I had huge sleep problems with Firefox 3 on two systems: iBook G4 14" and iMac G5 20", both OS X 10.4.11. The following workaround helped: Trash the urlclassifier3.sqlite file in your Firefox/cache/profile folder Go to Preferences menu --> Security --> uncheck the warnings for pishing and malware sites ("Tell me if the site I'm visiting is a suspected forgery" and "Tell me if the site I'm visiting is a suspected attack site") Clean Firefox cache whenever you end a session Disabling security warnings seems to be kind of stupid, but my Macs sleep again like babies, and that's more important for me... And sorry for my bad english, but I'm german speaking.
I have the same problem on a G4 with Mac OS 10.4.9 and FF3. You don't need to have a page opened, just FF3 launched. I add an activity sample, if you need. Please, fix it, this is very annoying… Thanks.
Attached file Activity sample —
A sample of the activity that prevent my Mac to sleep.
Well, after a few days, I must admit that none of my tips above really helped in the long turn. My final solution: I installed a quit-button in the menubar and simply quit the application whenever I walk away from the computer... FF 3 has some nice features - but in the end, it's just the good old "two steps forwards and three steps backwards solution" we see in a lot of software updates.
I've got the same problem, even in the released version. The only way I've managed to get the mac to go into sleep mode is to totally reboot; the other odd thing is that if I use FF after a reboot, the first hour or so I use it and I exit FF, the mac will sleep, the next time i use FF the no sleep behavior reappears. I wonder if FF's ping interval to check the connection or something prevents the sleep behavior?
Another vote for this bug, as I've got this issue under Mac OS X 10.4.11 on an Intel Macbook since upgrading from FF 2.X to 3.0.1. This is practically a show stopper for me and I'm considering swapping to Safari until this bug has been fixed. I'm sick of coming back to my mac to find the battery depleted! This seems to have been an issue since April, yet it's still an unassigned bug :(
(In reply to comment #11) > I'm sick of coming back to my mac to find the battery depleted! > Moreover it, it can be considered as a security issue. If a Mac is set to lock the account when the screensaver works or when it goes to deep sleep, Firefox will prevent it. So anyone can access to the computer.
Lots of folks at the Mozilla campus have macbook pros with leopard installed and no one has ever reported this. Can you reproduce this issue with all the extensions disabled?
(In reply to comment #13) > Lots of folks at the Mozilla campus have macbook pros with leopard installed > and no one has ever reported this. Can you reproduce this issue with all the > extensions disabled? Clint, disabling the extensions and using the default theme doesn't make it better. Still no sleep.
(In reply to comment #13) > Lots of folks at the Mozilla campus have macbook pros with leopard installed > and no one has ever reported this. Can you reproduce this issue with all the > extensions disabled? > Same here, I've disabled them and still no sleep. I'm not sure whether it's a function of extensions, or pop-up windows, or downloads or what, but something with firefox kills system low power sleep. The screen will go black, but it will not go into low power state. My iMac sleep if mail is open, itunes is open with an ipod connected and ichat running. FF is the only thing that kills it.
All extensions, themes, plugins etc uninstalled or disabled, and still the same issue. I've attached a screen grab showing the relevant version info etc, but is there a way to actually capture a log of some kind? There's nothing in /varlog/messages of any note...
Apologies for the bandwidth use, it seemed the quick way to definitively show a config that wasn't working.
Here's something. OK, she was sleeping fine today but of course, after using FF I closed it immediately. But later today, I had FF open and took a phone call, the computer monitor went to sleep. Woke it up and FF was open. I closed FF and now no deep sleep. The only way to get sleep back is to reboot the iMac. Can someone else try and see if this happens with your computer; maybe that's the trigger.
Same problem in Firefox 3.0.2 (OS X Leopard 10.5.4)! Every time FF is running my Macs won't sleep... Even if FF is the only running application.
This thread on mozillazine seems to indicate it is happening on Tiger as well: http://forums.mozillazine.org/viewtopic.php?f=38&t=726615&p=4149465.
t we're talking amongst ourselves as it appears it's not assigned to anyone nor has any one taken it on to look into it. But's its a real problem.
(In reply to comment #20) > This thread on mozillazine seems to indicate it is happening on Tiger as well: > http://forums.mozillazine.org/viewtopic.php?f=38&t=726615&p=4149465. > As me and other people said, this IS happening on Tiger. My activity sample is made on Tiger. So, WHY is this still "unconfirmed"?
Ok, I figured out how to reproduce this even on 10.4 So, here is the data: * On 10.4 & 10.5.x 1. Set the power options to sleep in 1 minute 2. Put the computer on battery power (it's easy to tell when a macbook goes to sleep because it flashes its power light 3. Open Firefox (either 3.0.x or 3.1a2pre) 4. Stand back and let the computer "sleep" == Expected == The computer should go to sleep == Actual == The computer will shut off its display but it won't actually sleep == Notes == If you close Firefox, the computer will sleep. I'm going to change the summary and the components for this bug to better identify the problem, and I'm going to confirm it (which will garner it more attention). Thanks for all the helpful reporting, folks. Confirmed in: Build identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1a2pre) Gecko/2008080602 Minefield/3.1a2pre
Status: UNCONFIRMED → NEW
Component: General → OS Integration
Ever confirmed: true
Summary: Firefox 3 beta 5 prevents "automatic" deep sleep on OS X Leopard (10.5.2) → Firefox prevents machine sleep on Mac OS X
FYI, one of the reasons it took so long to get this triaged, is that it was filed in the Firefox->General category. Not a lot of people watch this category because it generates about 100 messages a day. So, when you report, try very hard to put it in a component that matches the issue you're seeing. Sometimes, that's hard, but this one is a pretty clear cut case of OS Integration gone awry. Setting the wanted firefox flag on both branch and trunk releases as this is a pretty bad bug, and a very crummy UX, if you just leave your laptop open thinking it will sleep and it instead runs down your battery. It's also easily reproducible if you sleep the machine by leaving the machine up (not using the Sleep menu option or the close-lid option). By the way, can I get a volunteer to see if this is an issue on Firefox 2?
Flags: wanted1.9.0.x?
Flags: wanted-firefox3.1?
Flags: in-litmus?
Version: unspecified → Trunk
I can't reproduce this problem on OS X 10.4.11 (using FF 3.0.1, following the STR from comment #23). In step 1 I set "Put the computer to sleep when it is inactive for" to "1 min". After about 1 minute the screen blanked and the power light started pulsing (same as it does when you close the lid). Oddly, I wasn't prompted for an account and password when I "woke" my laptop -- even though I've checked "require password to wake this computer from sleep or screen saver" (in the Security prefs panel). But the same thing happens with Safari running, or without any app running. In a few minutes I'll try in OS X 10.5.4. I tested on an old MacBook Pro.
Version: Trunk → unspecified
I didn't mean to change the "version" from "trunk" back to "unspecified" (silly Bugzilla). But let's leave it that way for the time being.
(Following up comment #25) > After about 1 minute the screen blanked and the power light started > pulsing (same as it does when you close the lid). Oops, this is wrong -- following the STR from comment #23, I don't _ever_ see the power light pulsing (even if no app is running, and on both OS X 10.4.11 and 10.5.4). So I'm still not able to reproduce this problem, but (presumably) for different reasons. I need more information from those of you who _can_ reproduce it (or who think you can). The STRs in comment #0 and comment #23 are clearly missing some steps (and/or other information). And if you think you see this problem with Firefox, please be sure you don't also see it with other apps running, or with no apps running at all. Marcia, can you reproduce this?
Please try to use a few more minutes! If Firefox is running my two Macs switch off their displays but they don't enter sleep mode. Tested with a new user and a fresh Firefox installation with no addons and addtional plugins. No other apps running!
It clearly doesn't happen for everyone, which does make it harder to pin down. It happens for me on both my MBP and my Mac Pro, but then I'm running pretty similar software on both. Luckily, I also have a Mac Mini C2D which is used as media centre and has never had much software installed (and is set to never sleep), and is a Firefox virgin. Let's see how we go - step 5 gets us to current state: 1: Install Leopard, and all updates 2: Set sleep time to 'never' as this is a server really 3: Install Slim Devices Squeezecenter 7.1 4: Install MPlayer OS X 5: Install AlienBBC, proceed to use as media centre for 6 months ==> Start experiment 6: Install Firefox 3.0.1 7: Set sleep time to 1 minute 8: Start FF, import bookmarks, don't set as default browser, use FF homepage 9: Look at homepage very quietly 10: It goes to sleep after 1 minute Sorry if that was anticlimactic, but it is odd that I have a) A MacBook Pro that never sleeps if FF is running and always sleeps if FF is not running b) A Mac Pro that never sleeps if FF is running and always sleeps if FF is not running c) a Mac Mini C2D that sleeps just fine if FF is running I'm more than happy to run experiments, just tell me what to try!
(Following up comment #25 and comment #27) OK, I've now discovered the missing information I speculated about in comment #27. I've also found that Firefox 3 doesn't prevent machine sleep on OS X -- it just delays it. First, here are full and precise steps to make a MacBook Pro sleep as quickly as possible when no apps are running, without explicitly telling it to sleep (e.g. by closing the cover). They work on both OS X 10.4.11 and 10.5.4: 1) Put the computer on battery power. 2) In the Energy Saver prefs panel, set "Put the computer to sleep when it is inactive for" to "1 min" (this will also force "Put the display(s) to sleep when the computer is inactive for" to "1 min"). 3) Stop using your computer and wait. 4) After about one minute the display should go to sleep (go blank), and the power light should turn on (without pulsing). 5) After 3-5 more minutes, the computer should go to sleep (the power light should start pulsing). The need for step 5 was the crucial information I was missing earlier. As I said above, these steps "work" if no apps are running. They also work if Safari or Firefox 2.0.0.16 is running. But if Firefox 3.X is running and in the foreground, you have to wait 8-10 minutes in step 5 for the computer to go to sleep. The longer delay doesn't occur (you only have to wait 3-5 minutes in step 5) if Firefox is in the background or minimized. It makes no difference whether or not the network is connected while Firefox is running. It also makes no difference if some web page is displayed or a blank page is displayed (e.g. about:blank). Please tell me if you can reproduce these results.
Summary: Firefox prevents machine sleep on Mac OS X → Firefox 3.X delays machine sleep on Mac OS X
I suspect this is a cross-platform problem (e.g. that it also happens on Windows and Linux), but I'm unable to test this. I'd appreciate hearing from others who can test. Dave, I grabbed your name from a bug where you fixed a problem with phishing protection (bug 412688). Do you think phishing protection could be involved here? Could that be responsible for the disk writes reported in comment #0? If not, can you think of something else that might be causing those disk writes (or that might be causing this bug's problem in some other way)? Note that whatever causes this problem (the delay in machine sleep) only happens while FF 3.X is in the foreground -- not when it's in the background or minimized.
> The longer delay doesn't occur (you only have to wait 3-5 minutes in > step 5) if Firefox is in the background or minimized. > > It makes no difference whether or not the network is connected while > Firefox is running. It also makes no difference if some web page is > displayed or a blank page is displayed (e.g. about:blank). > > Please tell me if you can reproduce these results. > Very odd, that hasn't been my experience on my intel iMac or MB. If FF3 is running in the foreground or minimized it kills the sleep function entirely, there is no delay when it's open/minimized, the only thing that happens for me is the screen goes black and I get the non-pulsing light. Once it has been killed the iMac or MB won't sleep until I do a reboot or shutdown.
(In reply to comment #32) Does it make any difference if you follow my STR from comment #30 _exactly_? It's possible I still don't understand all the variables at play here. It's worth noting that I have very plain-vanilla installations of OS X (10.4.11 and 10.5.4) and Firefox on my old MacBook Pro (2 GHz Intel Core Duo). For example, I don't use any extensions with Firefox.
Another data point (possibly relevant) -- I use an Ethernet network connection, not a wireless one.
(In reply to comment #33) > (In reply to comment #32) > > Does it make any difference if you follow my STR from comment #30 > _exactly_? > > It's possible I still don't understand all the variables at play here. > > It's worth noting that I have very plain-vanilla installations of OS X > (10.4.11 and 10.5.4) and Firefox on my old MacBook Pro (2 GHz Intel > Core Duo). For example, I don't use any extensions with Firefox. > Yup, I've tried it all, months before I found this place. LOL. As I've said in a post earlier, another hitch is it appears my sleep is permanently killed if FF is open and the screen goes to black with non pulsing light. After I wake up the monitor go back to surfing and then close FF, sleep will not happen until I reboot or re-start. It's just very weird behavior and I'm grabbing at straws at this point and guessing at this particular trigger.
> It's possible I still don't understand all the variables at play here. Quite apparently I don't. But there's not much we can do about this until I (or somebody) does.
"Firefox 3.X delays machine sleep on Mac OS X" ?¿? ... DELAYS ??? I have waited 30 minutes and more in some experiments!!!
(In reply to comment #37) See comment #30 and comment #36. Rather than simply complaining that FF3 _does_ prevent/disable machine sleep on your computer, you need to do the following: Try my STR from comment #30 with no apps running, and then with FF3 running and in the foreground. If your results don't match mine (even in some trivial-seeming particular), report them here. This (of course) is just the starting point. But until we pass the starting point we can't do anything else.
(In reply to comment #38) 3 experiments with your STR: no other apps, Firefox without addons, sleep after 1 minute 1.) Firefox in background >> sleep after 3 or 4 minutes 2.) Firefox minimized >> sleep after 2-3 minutes 3.) Firefox in foreground >> sleep after 14 minutes I think my results match yours! one more: sleep after 23 minutes >> no sleep mode after more then 1h! I think Firefox was in foreground ... It seems that Firefox only preservs/delays sleep mode if it's in foreground.
(In reply to comment #39) Thank you, Stefan. > sleep after 23 minutes >> no sleep mode after more then 1h! I think > Firefox was in foreground ... I assume you mean that the display went to sleep after 23 minutes, but the computer still wasn't asleep after more than 1 hour. _Both_ of these figures are strange -- even the 23 minutes' delay before your display went to sleep. Please keep trying to find out how to reproduce this. In other words, try to find out what additional factor(s) is/are involved, besides FF 3 being in the foreground. > 3.) Firefox in foreground >> sleep after 14 minutes This is a little puzzling (your 14 minutes against my 8-10 minutes). Could it be caused by a difference in hardware? I've been testing on an early model MacBook Pro (15", 2GHz Intel Core Duo). What hardware have you been testing on?
I'm marking this qawanted to ask QA's help in testing, particularly in trying to reproduce my STRs from comment #30, and particularly to see if you get different results. Marcia? :-)
Whiteboard: qawanted
(In reply to comment #40) > I assume you mean that the display went to sleep after 23 minutes, but > the computer still wasn't asleep after more than 1 hour. _Both_ of > these figures are strange -- even the 23 minutes' delay before your > display went to sleep. :-) My system preferences: Display sleep: 9 minutes Machine sleep: 23 minutes Randomly chosen! ;-) I want my macbook to sleep after 23 minutes... but after more than 1h it dosen't sleep ... Display turns off after 9 minutes! > Please keep trying to find out how to reproduce this. In other words, > try to find out what additional factor(s) is/are involved, besides FF > 3 being in the foreground. > > > 3.) Firefox in foreground >> sleep after 14 minutes > > This is a little puzzling (your 14 minutes against my 8-10 minutes). > Could it be caused by a difference in hardware? I've been testing on > an early model MacBook Pro (15", 2GHz Intel Core Duo). What hardware > have you been testing on? My hardware: MacBook 2GHz C2D, 2GB RAM, GMA X3100, 120 GB HD It is the first model with X3100! I did all my experiments with a new user and a fresh Firefox installation. Only Little Snitch is running in background. That's everything I can change. All other processes are brought by OS X 10.5.4. In a few days I will test the same STRs on my iMac G5 (without battery mode :-)).
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x+
Flags: blocking-firefox3.1?
(In reply to comment #42) > My system preferences: > Display sleep: 9 minutes > Machine sleep: 23 minutes > > Randomly chosen! ;-) I want my macbook to sleep after 23 > minutes... but after more than 1h it dosen't sleep ... Display turns > off after 9 minutes! You really should have told us that you changed some of the parameters from those listed in comment #30. We need precision! But it's fortunate you thought to try new parameters ... because I'm able to reproduce your results! Where that leaves us I don't know, but it can't hurt to keep collecting good, verifiable information. In my tests (run on OS X 10.4.11 on my early model MacBook Pro (15", 2GHz Intel Core Duo)) I changed step 2 from comment #30 as follows: 2) In the Energy Saver prefs panel, set "Put the computer to sleep when it is inactive for" to "25 minutes" and "Put the display(s) to sleep when the computer is inactive for" to "10 minutes. I ran the test (from step 3 on) with Firefox 3.0.1 in the foreground. The display went to sleep at 10 minutes. But an hour later the computer still hadn't gone to sleep (the power light hadn't yet started pulsing). The "Start screen saver" setting (in the Desktop & Screen Saver prefs panel) made no difference to my result. For my first test I set it to "15 minutes", and for my second test I set it to "Never".
Summary: Firefox 3.X delays machine sleep on Mac OS X → Firefox 3.X delays/prevents machine sleep on Mac OS X
Okay, I recognized the problem. My two Macs sleep again. Two Firefox 3 sqlite files caused the whole trouble: urlclassifier3.sqlite and places.sqlite. It's a "dynamic" problem. There is a correlation between the (growing) size/complexity of those files and sleep behaviour. Sqlite is the new database format used for Firefox 3 (but not for Firefox 2). If you surf the web you will see that sqlite causes a lot of problems: CPU spikes, performance issues... Sqlite files are like blowfishes. Some data and a lot of empty space. The bigger they are, the more bloated they become. (Hope you understand what I mean. English is still not my mother language.) Step by step: Problem: Firefox 3 kills sleep on my two Macs, an iBook and an iMac. First step (see my first posts, comment #5 and comment #8): Trash the urlclassifier3.sqlite file and disable malware-/pishing protection. As I wrote, that worked, but only a few days. It only worked a few days because it was only part of the problem/solution. As I realized later, there are other sqlite files that grow and change over time and make additional problems... Second step: Two weeks ago, I looked into my other sqlite files. Places.sqlite (bookmarks, history, favicons...) had grown to 5 MB on my Macs. That was huge! 5 MB for 348 bookmarks and some history? I trashed the file on my two Macs and restored the bookmarks. New size was 700 kb. That was it. For the next three days, I DIDN'T HAVE THE SLIGHTEST PROBLEM!!! ON BOTH MACS! Nada, nothing. My iBook and my iMac slept again like babies. Great! I loved it. Unfortunately, the places.sqlite files grew in size over time. When they reached appr. 1 MB on both Macs on day 4, sleep behaviour again became random, was delayed, stopped working. Third step: I tried to keep my places.sqlite files as small as possible. Limiting history to two days (setting all history_expire_days settings in about:config to "2") and shrinking the file with SQLite Manager (Firefox add-on), using the "vacuum" command. And I trashed 100 old bookmarks. That helped. They slept again. Problem is, if I surf a lot, my places.sqlite files grow very fast (history entries). If that happens and sleep is disturbed again, I have to trash my history, shrink the file - and they sleep again. Of course, that solution stinks. Limiting history to just two days kills all the benefits of the so called "awesome bar". Summary: Sleep on my Macs is killed if urlclassifier3.sqlite reaches appr. 23 - 29 MB (I ran a test last Sunday on my iBook) and if places.sqlite grows to appr. 1 MB. And that means: Firefox 3 has problems to handle sqlite files that are either too big, too complex or too fragmented. I hope, my hints help. Good luck!
(In reply to comment #44) This does give me some ideas. I wonder if it is related to the recent "locking problem" we encountered w.r.t. sqlite. Cc'ing sdwilsh.
Another file you have to observe is places.sqlite-journal. Whenever I shrink places.sqlite, journal grows to epic proportions (which might cause additional trouble; if journal is too big it can kill sleep just like the other files). Closing Firefox and restarting the app minimizes journal again (from 900 kb to appr. 32 kb on my Macs).
(In reply to comment #45) > (In reply to comment #44) > This does give me some ideas. I wonder if it is related to the recent "locking > problem" we encountered w.r.t. sqlite. Don't think it's the case at all. (In reply to comment #46) > Another file you have to observe is places.sqlite-journal. Whenever I shrink > places.sqlite, journal grows to epic proportions (which might cause additional > trouble; if journal is too big it can kill sleep just like the other files). > Closing Firefox and restarting the app minimizes journal again (from 900 kb to > appr. 32 kb on my Macs). The journal file is used by sqlite to be able to rollback failed actions. When you VACUUM, it is going to use a lot more space in order to rollback data. sqlite does not shrink that files size once it gets large enough, but once you exit the process, it should go away.
So, I know that places does work when the user is idle - I think the preference says to start doing it after ten minutes of idle time. I'm not sure if that has any effect to this problem though.
(In reply to comment #44) Thanks for your detailed report. But it's (probably) not the whole story, since I can only partially reproduce your results. I gave myself a new profile and turned off the two settings you mentioned in comment #5 (Preferences : Security : "Tell me if the site I'm visiting is a suspected forgery" and "Tell me if the site I'm visiting is a suspected attack site"). Then, when I retested my STR from comment #30, I found there was no (significant) difference in the delay in step 5 between Firefox (3.0.1) running in the foreground, Firefox running in the background, and no apps running at all. But when I retested my STR from comment #43, my MacBook Pro still never went to sleep when Firefox was running in the foreground.
(Following up comment #49) In general, I find that (mostly following my STR from comment #30) my MacBook Pro will eventually sleep with Firefox in the foreground if I set "put the display to sleep" to 14 minutes or less and "put the computer to sleep" to 19 minutes or less. But it will never sleep (with Firefox running in the foreground) if I either set "put the display to sleep" to 15 minutes (or higher) or "put the computer to sleep" to 20 minutes (or higher). Shawn (or anyone else), do you know how to completely turn off all access to any sqlite databases?
(In reply to comment #49) > (In reply to comment #44) > > Thanks for your detailed report. But it's (probably) not the whole > story, since I can only partially reproduce your results. > As I wrote, urlclassifier.sqlite is only part of the problem (at least on my Macs). To reproduce the bug (if that is possible at all), you also need to look into places.sqlite (trashing history etc. to minimize it). And you should TRASH urlclassifier, not only turn off the settings. On my Macs, it's clearly size that matters.
(In reply to comment #51) Note that, in giving myself a new profile, I (presumably) got rid of my previous copies of _all_ the sqlite files. Also (as I said), I got different results depending on how long I set the computer to wait before putting the display to sleep and putting the computer to sleep. Are you able to reproduce _those_ results?
(In reply to comment #52) > (In reply to comment #51) > Also (as I said), I got different results depending on how long I set the > computer to wait before putting the display to sleep and putting the computer > to sleep. Are you able to reproduce _those_ results? Yes, I can reproduce them. Firefox running in the foreground. Screen to black in minutes / Mac to sleep in minutes 8 / 10: Mac sleeps 10 / 15: Mac sleeps (my usual settings) 15 / 20: Sleep is delayed or killed (I only waited half an hour to observe it) 20 / 25: Sleep is delayed or killed (I only waited half an hour to observe it)
My sleep problem isnt fixed yet, but I was prompted to check the size of the various sqlite backing files in my profile - places.sqlite was 23MB! After a vacuum it got down to a mere 9MB. That's still bonkers by any measure, but my opinion on that is I accept not really relevant to this problem.
Well, as I wrote, my Macs sleep again. And sqlite size/complexity seems to be a major issue in my case. There could be other variables, sure. Energy saver settings for example. Both my Macs go to sleep a few minutes too early. Not after 15, but after 11-12 minutes. Firefox somehow seems to screw up those settings. As long as they sleep, I don't care too much.
(In reply to comment #48) > So, I know that places does work when the user is idle - I think the preference > says to start doing it after ten minutes of idle time. I'm not sure if that > has any effect to this problem though. There is something else I don't understand: When my iBook is idle, Firefox 3 still continues to update/overwrite the places.sqlite file and -journal. I tried it out with various energy saver settings (5/15/25 = 5 minutes for screen saver, 15 for screen to black, 25 for sleep). 5/10/15 (my usual settings): iBook is idle, places.sqlite is updated a last time after appr. NINE, TEN MINUTES, a few minutes later the iBook goes to sleep. (If I use these settings and watch my sqlite files, my Macs always sleep; no problems.) 5/15/20: places.sqlite is updated a last time after appr. FOURTEEN, FIFTEEN MINUTES, a few minutes later the iBook goes to sleep. 5/20/25: iBook didn't go to sleep, but places.sqlite was again updated after 30 MINUTES of idle time. I mean, how can he sleep if places.sqlite is updated all the time? My workaround probably didn't work for others because there are indeed other parameters involved.
Depends on: 449124
(Following up comment #50) > Shawn (or anyone else), do you know how to completely turn off all > access to any sqlite databases? After looking at bug 449124, here's the answer, I think: 1) Turn off the following settings in Preferences : Security: "Tell me if the site I'm visiting is a suspected forgery" "Tell me if the site I'm visiting is a suspected attack site" Or set the following settings to "false" in about:config: browser.safebrowsing.enabled browser.safebrowsing.malware.enabled 2) Set the following setting in about:config to '0': places.frecency.updateIdleTime After doing this (and restarting FF 3), my computer slept (mostly following my STR from comment #30, with FF 3 running in the foreground) even using the following settings for "Put the display(s) to sleep when the computer is inactive for" and "Put the computer to sleep when it is inactive for": 15/15 15/20 Without step 2, my MacBook Pro fails to sleep with either of these combinations of settings. So I was wrong in comment #49, and the sqlite-database-access business _does_ seem to be the only cause of this bug.
(Following up comment #57) Actually, step 1 isn't necessary. All you need is step 2. In other words, all you (apparently) need to "fix" this problem is (in about:config) to set places.frecency.updateIdleTime to 0. I'm not sure what the implications are of doing this, or whether it's wise to do so. But the fact that it "works" implies that a fix for bug 449124 should also fix this bug. All you who've commented here about seeing this problem, please try this setting.
(In reply to comment #57) This worked!!! Thanks you for finding this out. Can you tell me, do you know if: What other settings does this impact or how do these changes impact history, etc? Would lengthening the frequency work as opposed to turning it off completely (60000=1 minute to say a longer frequency)? What about Phising, is there an alternative to use instead of what's built in?
(In reply to comment #58) > (Following up comment #57) > > Actually, step 1 isn't necessary. All you need is step 2. > Odd, I did steps one and two together earlier and she slept with FF open and in the foreground. I went back and put ticks back in the phising options from step one aand poof..it stopped sleeping. :( So at least for me, step one and two is needed.
I already had the first two options in Step one (from comment 57) disabled anyway, so when I disabled the further option in Step 2, my Macbook now sleeps perfectly! I've yet to test re-enabling the first two options to see if this prevents sleeping.
This workaround seems to work. I had disabled places.frecency.updateIdleTime already yesterday. So far, my Macs sleep, and I don't have to watch my places.sqlite files anymore. They have grown to appr. 1.3 MB and are still growing. At least on my Macs steps 1 AND 2 are necessary.
So, the complete workaround would be: 1) Disable places.frecency.updateIdleTime, and, if that alone doesn't work: 2) Trash urlclassifier.sqlite and disable malware-/pishing protection. I think that CPU speed could be part of the problem. When I surfed the web to find a solution I came across some reports that said sqlite files caused problems on slower PCs/Macs. They just need more time to process all the stuff.
(In reply to comment #63) > 1) Disable places.frecency.updateIdleTime, and, if that alone doesn't work: I can confirm this did the trick for me without needing step 2 > I think that CPU speed could be part of the problem. Possibly in some cases, but I had the problem on a 2.8GHz quad core Mac Pro
very odd...the trick works on my imac; but not on my black macbook (late 2006 model) sigh.
> very odd...the trick works on my imac; but not on my black macbook (late 2006 > model) sigh. You mean your black macbook won't sleep even using both step 1 and step 2 from comment #57?
(In reply to comment #67) > > very odd...the trick works on my imac; but not on my black macbook (late 2006 > > model) sigh. > > You mean your black macbook won't sleep even using both step 1 and step 2 from > comment #57? Nope, i set it up, it was plugged in and my iphone was attached and charging but it wouldn't go to sleep. Gonna test tonite to see if it sleeps before I open FF. my imac sleeps with the iphone connected and everything though. So I'm confused to say the least.
(In reply to comment #67) > > very odd...the trick works on my imac; but not on my black macbook (late 2006 > > model) sigh. > > You mean your black macbook won't sleep even using both step 1 and step 2 from > comment #57? OK, it works on the mac...the ipod isn't connected...nor is my jawbone headset which I was also charging last night.
Depends on: 453181
No longer depends on: 453181
The work-arounds from Comment 57 do not change the behavior on my Powerbook 1.67GHz running OS X 10.4.11 and Firefox 3.0.1. It will not sleep while FF is running, foreground window, or background, or hidden. When firefox is not running, sleep works fine.
(In reply to comment #70) > The work-arounds from Comment 57 do not change the behavior on my Powerbook > 1.67GHz running OS X 10.4.11 and Firefox 3.0.1. It will not sleep while FF is > running, foreground window, or background, or hidden. When firefox is not > running, sleep works fine. I take that back; if I set the places.frecency.updateIdleTime to something longer than my sleep timeout, then it will sleep. My guess is that the fix will be to only do the frecency calculation once during the browser idle period; I'm guessing that the calculation is being done every 60000 milliseconds (i.e. every minute) during an extended otherwise-idle period -- essentially recalculating the same results over and over again, with the side-effect of hitting the hard disk and so preventing the sleep.
Bug 457481 is mostly a dup of this one, but reports some new symptoms.
Weird. I tried setting the places.frecency.updateIdleTime to 0and everything was fine for a few days. MacbookPro 10.5.5, FF 3.0.3. Maybe it was the upgrade to 3.0.3 (previously 3.0.1), but figured I would ask if anyone saw this happen too. I tried delete all the sql files mentioned here and also creating a new profile. Nothing helped since it stopped working again. I'll report back after I downgrade to 3.0.1.
Turns out downgrading to 3.0.1 and keeping the places.frecency.updateIdleTime at 0 makes sleep work again. So for me, there was an issue in 3.0.3 that prevents sleep again.
Now my places.sqlite is 13,8Mo and I think it causes an other bug, Firefox doesn't remember my new bookmarks or when I move them from a folder to an other, or if I modify a bookmark, or if I create a new folder. So, FF3 works well is you don't use it a lot! :P Please, fix it and thanks for your job.
On my Mac Pro Desktop running OS 10.5.5 and Firefox 3.0.4, opening Firefox once kills sleep, even after I close the program. I.E., I open Firefox and immediately close it, and sleep still will not work days later. If I reboot sleep works fine until I start Firefox, then she is toast. I'm not sure why that is, and maybe it is a bug from within Mac that is causing my issue to be a little more severe (I can't wake the computer half the time, either), but I thought I would point it out just in case it is related. Like with bz101, on 3.0.4, changing the frecency.updateIdleTime does not help me. I have not tried reverting to 3.0.1 to test bz101's solution.
Update: Changing the updateIdleTime on 3.0.4 did in fact allow my Mac to go to sleep properly. Curiously, if the value is set to 0, will frecency still update at launch, or does "0" disable it all together?
This was originally filed on the 3.x branch, but I am wondering if anyone running 3.1 or the trunk has seen this? ctalbert mentioned today on IRC he might have a hit of variant of it, but he is running 3.1 branch and trunk.
Changing the updateIdleTime on 3.0.5 did not seem to solve my problem, I will try also turning off the security options (is this safe?)
Now using 3.0.5, I changed the updateIdleTime to 1200000, and now the Mac sleeps as it should. Frecency on visited websites still updates immediately (or at least at the same rate that it did using the default setting). I am using TagSifter and have my bookmarks sorted by frecency, and they change order almost every time I visit a bookmarked page, so I know it is working properly. I'm not sure what I am missing by increasing the IdleTime to a very high level, but it doesn't appear to be anything.
I had this problem intermittently on macbook pro running tiger I have updated to the current Beta 3.1b2 and the problem has not yet re-occurred has anyone else tried 3.1b2?
Component: Shell Integration → General
This won't block, and as far as I can tell, we don't have a confirmed reproduction on 3.1. We'll need that before we would consider blocking, but even then, feels like it's pretty niche.
Flags: blocking-firefox3.1? → blocking-firefox3.1-
Flags: blocking-firefox3.1- → blocking-firefox3.1?
Flags: blocking-firefox3.1? → blocking-firefox3.1-
This bug should probably be added to the Known Issues list for FF 3.0.x under the Mac platform. Preventing sleep causes system crashes when the battery expires - users ought to be made aware of this without having to locate and dig through bug logs.
Any progress on this bug? BTW, there's a similar bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=479001
BTW, I'm running nightly builds (shiretoko) on 10.5.6, and I'm using a brand new iMac as well as a 2-year-old MacBook Pro. This is definitely still a problem. Sleep is prevented entirely. The longest period I've let the iMac not sleep before manually putting it to sleep is about 8 hours.
It's a shame this isn't considered a blocker for 3.1, and that there's no confirmed reproduction. What does it take to get a confirmed reproduction ? At home the typical use for our computers is to wander up, wake one up, use it and wander off. I think that's quite typical for Mac users these days. It seems like a massive step backwards to sleep it manually, and (of course) the kids don't. That's a lot of power getting wasted :( FWIW I'm running 3.1b3 on 10.4.11 on a 20" 2GHz Core Duo Intel iMac and a 800MHz PPC iBook. Neither of them sleep when running Firefox, even just a single blank window.
It's definitely still a problem and will no longer use Firefox on any of our macs until it's fixed. Safari has never had this problem and V4 is now basically as good as firefox in terms of features so we're using that exclusively now.
I have Shiretoko on two Macs, and the workaround does the trick for me. To to about:config, and set places.frecency.updateIdleTime to 0.
Of course, the work-around means that some database isn't being updated. The field sets some time delay between when the user stops doing things and when the database starts updating. The default is about a minute. Why it keeps the machine from sleeping is beyond me. And as for why developers aren't fixing it, developer attention to bugs is kindof hit-or-miss. Private browsing is being actively worked on, which is interesting, because the feature only exists as Google Chrome catch-up. Some other features that I thought were important (e.g. the ability to undo tab and window close) are also being worked on actively. What gets fixed comes down to a combination of what the developers are interested in and some kind of ad hoc triage. This bug doesn't cause a crash or data-loss, and there's a reasonable work-around that seems to work for most people. This bug, by far, is not the oldest one that's been overlooked.
I've been using this utility http://homepage.mac.com/rwikoff/slicedapple/nmsutility.html and my sleep problems are non-existent until they fix the browser.
Well, at the risk of adding complete confusion to this problem I have to report that my macbook is now sleeping properly running FF 3.5pre. From what I can tell on this thread no specific action was taken to correct the issue but it is now not a problem. Perhaps fixing some other bug had the unintended side-effect of fixing this one as well?
BTW - I should add that it doesn't sleep exactly at the time that I have configured in system preferences, energy panel. That is, if I set the mac to sleep in 1min. it actually sleeps 1:30 to 2:30 later. The delay could be for other system activity I suppose.
Well, I'm using 3.5pre (the lastest Shiretoko nightly build), and my MBP still doesn't sleep if FF is open. BTW, I'm now using 10.5.7. Also, I've noticed that the "work around" that sets frecency to zero and disabled a few other sqlite-related things no longer works. I had the work-around working on my iMac, but now it doesn't sleep anymore. I think it may be affected by what pages are open, though.
Does anyone have a C development/debugging environment installed on their Mac (if such even exists?) In particular one needs the strace and/or gdb programs to run them on Firefox. I think the Mac OS is based on BSD (can anyone confirm?) and if so, these packages should be available. I am particularly interested in whether the Mac auto-sleep problems are similar to the Linux ondemand CPU scaling problems (Bug #504990). If so the problem appears to be improper/excessive use of poll()/gettimeofday() calls which prevent the CPU from thinking it is "idle". I'm still trying to get a handle on why because there is some complex interaction between Firefox threads and the gtk/gdk libraries. It is worth noting that the sqlite source does have timeout code in it and sqlite may be a "journaled" DBMS so there may be periodic (frequent?) checks to see if the journal and database need to be reconciled. I have noticed that a running instances of Firefox do seem to have all of the *.sqlite files in the profile directory open.
Apple's development/debugging environment is called Xcode, and is a free download: http://developer.apple.com/technology/tools.html In Xcode there is a tool called Instruments which can obtain detailed tracing information about running programs.
You guys make it sound like there are no developers currently working on the MacOS port of Firefox.
Haha, of course not... I was just answering Robert Bradbury's question, in the hopes of helping someone out there gather useful data.
Well, this bug has been sitting around for a year and a half with no attention. I realize that Firefox has bugs even older than that, but this one is pretty serious. This bug and the fact that Firefox is a massive CPU hog (search bugzilla for "high cpu usage" and count the bugs) makes Firefox downright hostile to notebook users. When Firefox 3 came out, it was lightyears ahead of Safari. But now Safari has caught up and kept going. If you use a Mac and want a browser that works well and doesn't waste battery, consider using Safari with Saft. The main advantage Firefox has over Safari is that Firefox has better memory management, but there's little point since you don't want to have too many tabs open in Firefox anyhow, owing to the additional CPU usage for each tab. As with so may other products, Firefox devs care mostly about Windows. They're driven to knock Internet Explorer off its pedestal. This is a GOOD thing. IE is absolute garbage, and Microsoft isn't going to fix that any time soon. It'll be a long time before any other browser (even Google Chrome) catches up to Firefox on Windows. But for Linux and Mac, you're better off using something else.
Timothy has my sympathy, but my expertise is Linux so I can't help much. There are three possible "culprits" IMO that are possible here: 1) Javascript timeouts; 2) Sync'ing to the sqlite journal files; 3) Continuous file (fd) poll()ing for pending I/O. I know that #3 is a major contributor and #2 might be a minor contributor under Linux. #1 is easy to test (try seeing if the problem occurs with a browser window open to nothing (about:blank for example) and with Firefox started with Javascript disabled (in preferences). Then compare the results with a page with some active content, e.g. newspapers or industry rags with some ad-pages that have periodic updates (may or may not use Flash to do this)). Gmail is an alternate possibility (since it is a heavy use of Javascript). I'm not sure if you can set Gmail for things like "only check for mail every 30 minutes"; or perhaps change the browser status so it is "offline". Clever use of NoScript is another possibility. After you have the Javascript question out of the way you have to deal with the sqlite and/or poll, esp. gtk poll question. Under Linux you can use "strace" to monitor system calls and watch things like the poll()/gettimeofday() calls that commonly occur very frequently in "quiet/unused" Firefox sessions. If you see fcntl()/open()/creat()/write() calls those are most probably due to periodic updates to a sqlite journal files (under Linux Firefox keeps several sqlite databases (cookies, downloads, urlclassifier, places, etc.) which may be subject to "autoupdates") (often due to auto-page-updates driven by Javascript to active-media websites). Now the way out of the sqlite problem is either to disable Javascript or use Noscript to minimize its activity. The way out of the poll() problem is more complex and depends on whether Firefox is using the standard X-server "libglib" interface. If it does it seems to use the default g_poll() call which redirects to the system poll() call (poll(2)) though there are comments in the glib/gpoll.c that suggest that OS/X has a non-standard poll() call which must be emulated. The problem is that the default poll() call is sub-optimal for a program like Firefox and needs to be replaced (there are hooks in glib/gmain.c:g_main_context_set_poll_func() to allow applications to replace the default g_poll function with one which is more application aware, but to the best of my knowledge Mozilla/Firefox has not done this on Linux and presumably OS/X. (Typically under Linux Firefox may be monitoring (polling) 7-13 file descriptors / sockets for I/O activity even when it is "idle".) The proper way to poll() when dealing with "idle" processes is to increase the poll timeout time to reflect an ongoing lack of file/socket I/O but the default function doesn't do that. But do beware that there is extensive timeout functionality built into Javascript and web sites are increasingly using that to "take over" your computer to suit their purposes (which is one reason that Javascript is evil and should be considered a security risk). So whether or not one can enter low power states may be under the control of remote web sites.
Is there any reason that Firefox would be canceling sleep deliberately via an API call? Today I see the following in my /var/log/kernel.log: Nov 1 18:03:21 mini kernel[0]: PM notification cancel (pid 586, firefox-bin) Nov 1 18:03:21 mini kernel[0]: IOPMrootDomain: idle cancel (repeats periodically while the machine is idle, at intervals somewhat less than 15 minutes, which is the automatic sleep interval) My machine was automatically sleeping successfully for the first time last night (after finally noticing and shutting down an unrelated hard disk-accessing server process). But today this popped up, which sort of makes it look like Firefox is causing a deliberate cancellation somehow. I noticed that in seamonkey/source/widget/src/cocoa/nsToolkit.mm, Firefox registers for sleep/wake notifications--but it seems to be set to always allow sleep, so I'm not sure why this would happen. (Firefox 3.5.4, OS X 10.6.1, Mac mini early 2009)
I discovered that the problem from my previous comment is related to the Flash plugin. If I disable the Flash plugin (using Plugins Toggler for this), my machine can sleep. With Flash enabled, it always gets the 'idle cancel' message and sleep is prevented. So if you're investigating this bug, you might want to consider this factor and check your /var/log/kernel.log.
(In reply to comment #102) > I discovered that the problem from my previous comment is related to the Flash > plugin. If I disable the Flash plugin (using Plugins Toggler for this), my > machine can sleep. With Flash enabled, it always gets the 'idle cancel' > message and sleep is prevented. > > So if you're investigating this bug, you might want to consider this factor and > check your /var/log/kernel.log. Perhaps this bug may be related to bug 513048? (In particular, the steps to reproduce for that one -- bug 513048 #46 -- seem to rely on one or more plugins being loaded as well.)
So is this a bug in sqlite/storage, or two separate bugs in the implementations of Places and url-classifier and how they manage their database access? That is, can we move this bug to Toolkit:Storage, or do we need to file a bug on Toolkit:Places and a bug on, um, Toolikit:ThereIsNoBugzillaComponentForUrl-ClassifierAndThatMakesMeSad, given that these are both/all components used in multiple products?
This is not a storage bug.
I've noticed something. If I leave the machine idle, the system won't sleep, but the hard disk will spin down. This means that whatever Firefox is doing to prevent sleep, it's not related to disk I/O.
Tim, the fact that the hard drive spins down would tend to rule out #2 from my comment #100, e.g. sync'ing the sqlite journal files. As I discussed, when one straces a "idle" firefox session under Linux one finds it is never "idle" -- it is constantly doing poll()'s and a large number of gettimeofday calls. In most of my sessions, which are relatively large, it may be polling anywhere from 9-13 file descriptors. As I believe only one of these is between firefox and the X server, one can only assume that most of the rest are open sockets which are kept open by specific web sites (most often due to active Javascript and/or rotating advertisements). I would suggest that you take a session which fails to go into idle mode, turn off Javascript, then exit firefox and restart and resume the session without any Javascript and see if the behavior changes at all. It may or may not. There is still the problem that Firefox (and all the other browsers to the best of my knowledge) do not degrade the timeout period on poll calls to reflect browser/display-manager inactivity, i.e. the poll's & timeouts continue at a fixed rate even if one hasn't touched the browser/display in several hours (which of course is improper behavior if one is at all concerned about being green, battery lifetime, etc.). But the powers that be seem to think that how fast Javascript runs is the only thing that matters (when some of us would like to see Javascript thrown back into the chasm from hell from which it arose).
I should clarify. I've noticed cases where when I come back to the Mac after it's been idle, the disk has spun down, and I can hear it spin up when I start using it again. But this does not always happen. Quite often, the only thing that is asleep is the display. (I've never observed a problem with putting the display to sleep.) There may be multiple independent things that each can prevent sleep.
What happens if you disconnect from the network? I'm pretty sure network traffic can also keep a Mac awake. FWIW, I've observed this behavior with Chrome as well.
Why did I just get an email stating that this has been resolves and WORKSFORME? This bug is not fixed!
Someone asked me privately if I had used a trunk build to determine that this is still a bug. I decided to try a slightly more controlled experiment, so I used a different user account on a different Mac that had just been rebooted, with no apps running other than Minefield (as of Dec 18, 2010). The machine will go to sleep if Minefield is not running. It will NOT go to sleep if minefield IS running. I left open the following set of tabs, and left the machine idle for several hours: // First window - My gmail account - http://ezinearticles.com/?How-to-Teach-Your-Baby-to-Read-With-Flash-Cards-Using-5-Simple-Steps&id=4314500 - http://www.childandme.com/howteachbabyreadenglish/ - http://www.mediafire.com/FleschCards - My hotmail account - http://en.wikipedia.org/wiki/The_Silmarillion // Second window - http://store.apple.com/us_edu_380982/configure/MC516LL/A - http://buyersguide.macrumors.com/ - http://store.apple.com/us_edu_380982/configure/MC504LL/A - http://en.wikipedia.org/wiki/Made_in_U.S.A._%28album%29 // Third window - http://movies.netflix.com/WiPlayer?movieid=70141114&trkid=2430625 [Due to another Minefield bug, all this page says is "Once installation is complete please restart your browser to watch this movie." The silverlight plugin is not actually active.] - http://en.wikipedia.org/wiki/List_of_The_Venture_Bros._episodes - http://www.imdb.com/title/tt0041386/plotsummary - http://www.vegansecrets.com/blog/?p=221 - http://www.coe.montana.edu/ee/rosss/Courses/EE578_Fall_2008/HW05/IPA_vowel_chart_2005.png - http://en.wikipedia.org/wiki/Resveratrol - http://en.wikipedia.org/wiki/Steven_Moffat - http://tardis.wikia.com/wiki/Steven_Moffat - http://en.wikipedia.org/wiki/Arsenic - http://www.mozilla.org/projects/firefox/prerelease.html As far as I can see, the only pages with any active javascript are the two email accounts. I have AdBlock, so I shouldn't have any flash plugins or animates images (although those shouldn't be permitted to prevent sleep anyhow). The silverlight plugin doesn't work. And with regard to the two email accounts, I've had them open lots of times with Safari, and the machine will still go to sleep. This Bug Is Not Fixed.
Guys, this bug has not been closed. It was one of its dependencies that was closed. This bug is still marked as NEW / qawanted.
Here is the question: Does the MAC OS have an strace-like utility? Or alternatively, does it use libglib, e.g.: /usr/lib/libglib-2.0*? I don't have/use a MAC so I cannot answer these questions. But if it does use libglib (and I've looked at the source code and it appears to be written so that it will run on Windows or MAC), then the problem is likely to be in the way Firefox uses poll() calls. It does periodic poll'ing every N milliseconds so the machine is *NEVER* idle. If instead, it setup the poll() calls so that they would "hang" on inactivity to files and/or sockets and were only active when the mouse or keyboard were active (e.g. when there is a user operating the machine -- and actually requesting that Firefox do something...) -- *then* you would have an "idle" machine which should go into power conserving mode. This is an obvious problem with the way almost all browsers are setup [1] (and which nobody has bothered to seriously investigate). The problem is readily apparent if one simply does an strace on the program [2] and watches the endless stream of poll()/gettimeofday()/read() [3] calls which do nothing. Interestingly enough one sees similar, though less intensive behavior when the browser is restarted (after being killed/shutdown) and there is only a single window asking whether to restore the previous session. One can observe endless attempts to open directories which do not exist. One thing which would help is for people to explain *what* utilities are used under Windows/MAC to monitor program system call activity. If one could get a developer to pay some attention to that we might get some progress with respect to useless (non-GREEN) browser activity. 1. The Windows interface probably doesn't use glib so it may not appear in Windows which may explain why it is largely ignored by developers. 2. Or in chrome the process which manages the X window. 3. The hooks *do* exist in glib to allow developers to replace the default polling system with one which is more intelligent (delaying poll timeouts based on length of inactivity). I have mentioned these hooks both in chrome bug reports as well as, I believe, older firefox bug reports, but they apparently continue to be ignored.
Yes, OS X 10.5+ comes with an strace-like utility called "dtruss". And, even better, it also comes with "dtrace", which is the general front-end to Sun's DTrace debugging facility which Apple ported, and which "dtruss" is based on: http://www.mactech.com/articles/mactech/Vol.23/23.11/ExploringLeopardwithDTrace/ With DTrace one can write custom tracing scripts which analyze exactly what you're after, while ignoring all the junk you don't want and not impacting performance much.
Flags: wanted-firefox3.5?
Is this still an issue with recent Firefox builds ?
Oh Geez, I haven't even thought about this bug in years. I still have a mac for my personal machine at home (I run windows now at Moz) but I haven't seen this bug in years. So, it hasn't reproduced in my experience. --> WFM?
WFM!
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME

Hey guys,

It seems FF prevents "automatic" sleep on Mac OSX Leopard. Sleep works fine when shutting the lid on my Macbook Pro or forcing sleep using the apple menu. and used to create and develop one of the website and this bug arise in creating website using code ignitor https://www.al-baik.com/ in this client website in mac os Firefox don't update code properly ????????

Looking at activity monitor it looks like FF writes to disk at least once per minute. While the display will go to sleep this disk activity prevents automatic deep sleep of the system.

It seems to happen in the "automatic" sleep on Mac connect with the os and sometimes it will be connected to the system. Sleep works fine when shutting the system on the MacBook system or forcing sleep using the pro-business id. and used to create and develop a website on the MacBook and this bug arises in creating a website using code framework in this website https://www.al-baik.in/ in this client website in mac os Firefox don't update code properly check this out and post the thing here.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: