356762 - Firefox doesn't prevent Windows from going into suspend mode while active downloads remain

Status: NEW

(Toolkit :: Downloads API, defect, P3)

Description

[Andreas Heyer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7

When there are active lenghty downloads in the download manager and Windows power policies are set to go to Standby (suspend mode) after some idle time, FF doesn't prevent Windows to go into suspend mode. If you wake up your system again, all active downloads are stalled somewhere in the middle. You have to restart when the  download server doesn't support resume mode.

Reproducible: Always

Steps to Reproduce:
1. Set Windows power scheme to Home/Office Desk an configure Standby timeout
2. Start lengthy download over a slow connection
3. No more user interaction or other active programms to let Windows go into Standby

Actual Results:  
After wakeup, the download is stalled. Most of the time the resume function of the download manager doesn't work.

Expected Results:  
FF should reply to WM_POWERBROADCAST in the right way, i.e. returning BROADCAST_QUERY_DENY when there are active downloads.

I checked the sources for current FF 1.5.0.7. and I have a patch (maybe). The only problem is that I possibly don't know how to get an interface to the download manager. My suggestion is just a try. But I don't have cygwin to build and test. So I hope for your help and a port to FF 2.0.

Inside mozilla/widget/src/windows/nsWindow.cpp there is a handler for WM_POWERBROADCAST (Lines 4368-4384). Add a case brach:

case PBT_APMQUERYSUSPEND:
	nsCOMPtr<nsIDownloadManager> dlMgr(do_GetService("@mozilla.org/download-manager;1"));
	NSInt32 count;
	dlMgr->GetActiveDownloadCount(&count);
	if(0 != count)
	{
		*aRetValue=BROADCAST_QUERY_DENY;
		result=PR_TRUE;
	}
	break;

Comment 1

[Adam Guthrie]

So your patch would prevent Windows from going to sleep if Firefox is downloading something? Does IE do this?

Comment 2

[Andreas Heyer]

(In reply to comment #1)
> So your patch would prevent Windows from going to sleep if Firefox is
> downloading something? Does IE do this?

Do you really want to compare FF with IE? ;-)
Ok, I really don't know what IE does. When I last used IE for browsing I had no ADSL connection, so I never startet huge downloads because that would be frustrating. But it`s also frustrating when I start a 200 MB d/l in FF today, left it alone, and when I return to my PC it was stalled with 50 MB and d/l managers resume function do not work.

In my opinion you can call it a bug in Win XP SP2 because my OS threats socket traffic and small FF disk action as idle state. On the other hand, you have the possibility to deny standby mode just with a simple reply to WM_POWERBROADCAST. 

Maybe the bug is better treated as a feature request?

Comment 3

[Robert Strong (they/them - no direct email)]

Not a shell integration bug... possibly download manager

Comment 4

[Andreas Heyer]

Wow, a new comment after 5 years! ;-) But the problem still remains with FF 4 on Windows 7.

IMHO it is a shell integration bug in download manager. A better approach than the reply to the window message would be to use the SetThreadExecutionState function inside the download manager. The example code inside the MSDN documentation (http://msdn.microsoft.com/en-us/library/aa373208%28v=vs.85%29.aspx) of this function seems perfectly suitable, regardless of the comment that browser do not need this function.

Comment 5

[Robert Strong (they/them - no direct email)]

Bugs often don't get looked at when they are misfiled. To remedy that problem, I've requested removal of the shell integration component

Comment 7

[VanillaMozilla]

(In reply to Robert Strong [:rstrong] (do not email) from comment #5)
> Bugs often don't get looked at when they are misfiled.

It would have been helpful if Shell Integration maintainers had passed it on and moved it out.  Confusion over the component or product is a common occurrence, and it would be extremely helpful if people would extend this common courtesy.

Comment 8

[Patrick Storz]

Since this is a long-standing bug it would be great if it could be finally fixed.

There's even a quite simple Add-On that offers the functionality requested here:
https://addons.mozilla.org/de/firefox/addon/no-sleep-download/?src=api

I guess it wouldn't be much of an effort to finally implement it directly into Firefox.

Comment 9

[Christian Eyrich]

Attachment: Port of the addon code to Firefox.

The attached patch is a port of the addon "No Sleep Download" from comment 8.
It does fix the problem for me on Windows 8.
What I wasn't able to find out is how to test if we're running on Windows in disableSleep() and restoreSleep(). I'd like to get the code that it's extendable for Linux and Mac (if the problem with the overly aggressive energy saving algorithm does exist there at all).
For the time being I added it to the makefile where it gets only included when build for Windows.

Comment 10

[Christian Eyrich]

Attachment: Patch for SeaMonkey to get this feature.

Comment 11

[Philip Chee]

Comment on attachment 714902 [details] [diff] [review]
Port of the addon code to Firefox.

You need to set the reviewer flag to someone if you want this code reviewed. But this patch needs a lot of rework so I'll use the feedback? flag instead. I suggest Mak or Dao.

Comment 12

[Marco Bonardo [:mak]]

Comment on attachment 714902 [details] [diff] [review]
Port of the addon code to Firefox.

This is not a trivial change, most likely, if this is the wanted behavior, it should prevent standby only if any of the downloads is not resumable, not if any download exists.  And probably could also take into account the battery API to tell if we are running on battery.
That said, this is the usual case where we can't satisfy everyone, there will be users saying standby requests should always be satisfied for power-saving reasons, and those stating downloads should never be interrupted.  A compromise will have to be figured out even before making a patch.

I think the above request to verify what other browsers are doing (Safari on Mac, IE on Windows, and maybe Chrome even if it's not really native for any platform) makes sense in this vision, not really to "copy" someone else, but rather to figure what's the most commonly expected behavior for users today. susprising users is often not a very good thing even with very valid reasons.
So I'd appreciate having this comparison data.

Regarding the patch, we can't just take this module approach, it is pretty good for an add-on, but to integrate it into the product the logic should probably be added to toolkit/components/downloads/nsDownloadManager.cpp

Comment 13

[jakub.g]

I remember I used to have a warning dialog from Windows Media Player 11 under Windows XP when tried to hibernate (via laptop's power button which I've bound to hibernation in my system settings) while listening to a radio stream, asking if I really want to hibernate.

I probably ticked "Do not ask me again" and now I can't find out how to reenable this however (not that I need it, but just to give some way for testing).

Unfortunately none of the applications in the internet advertising as "you'll never suspend/hibernate while I'm running" worked for me later on Win XP (not sure - maybe this is connected to some registry settings, or perhaps some Windows updates changed the behavior).

Comment 14

[Martin F.]

(In reply to Marco Bonardo [:mak] (Away Mar 1) from comment #12)
> This is not a trivial change, most likely, if this is the wanted behavior,
> it should prevent standby only if any of the downloads is not resumable, not
> if any download exists.  And probably could also take into account the
> battery API to tell if we are running on battery.
> That said, this is the usual case where we can't satisfy everyone, there
> will be users saying standby requests should always be satisfied for
> power-saving reasons, and those stating downloads should never be
> interrupted.  A compromise will have to be figured out even before making a
> patch.

While I can see the point of saving as much energy as possible when on battery, for a system running on mains, I would hate the standby mode occurring even on resumable downloads. Let’s say I have the standby timeout on 20 minutes, the download takes 30 minutes, I leave the PC to take a meal. When I get back to the PC after 30 minutes, I expect the download to be finished. I would lose 10 minutes in that case. Or if the download would take some hours, I don’t want to change my power settings to leave the PC on all night. I would have to reset the settings the next day and also it would really waste energy because the PC will be on even when the download is already finished.

Some tasks should just finish without entering standby. I don’t want standby while burning a CD, copying files to another harddisk, downloading files from the internet, listening to music or watching a movie. I could certainly resume the movie, but it’s inconvenient.

Also, when Firefox disables standby while downloads are active, you get “standby when downloads are finished”, which some download managers offer, for free — no additional GUI elements, no manual settings you have to set for this specific download queue, no extra software — just a nice integration in the power settings of the system. (There may be an additional delay due to the timeout, but that’s not so bad.)

If there was a pref to choose when standby should be disabled, I would definitely choose “on mains, even for resumable downloads”. I’m not sure about the case when running on battery.

As a reference, µTorrent allows to choose whether standby should be possible or not while “torrents” are active.

Comment 15

[Philip Chee]

> This is not a trivial change, most likely, if this is the wanted behavior,

On the other hand Bug 335418 (Pause downloads when computer is about to go to sleep) implies that the current behaviour is (or was) wanted.

Comment 16

[Andreas Heyer]

As opener of this bug or maybe better feature request I'd like to ask what's the behaviour on other OS? Even on Windows 7 the OS doesn't seem to consider Net-IO as workload that prevents a power saving mode. And even with a 16MBit/s connection I manually swap Windows' power saving plans when doing lengthy downloads. Fortunately that do not happen too often with a fast connection.

So what happens with FF downloads on Linux or OSX? Do these OS also sacrifice Net-IO for power saving? Or is it just "bad behaviour" of Windows?

One word according the implementation of the feature: IMHO you "only" need an additional 3-valued setting (Let_OS_decide, Prevent_On_Mains, Always_Prevent), the APIs SetThreadExecutionState and GetSystemPowerStatus and a WM_POWERBROADCAST handler.

Comment 17

[Christian Eyrich]

For me starting a download sets the clear target of finishing the download and going to sleep before it's done violates that target.
On computers running on battery asking the battery API as Marco noted and reenabling sleep if battery is low seems like a good compromise to me.

But I understand that others may have other objectives. So providing this feature as an addon only might be no bad idea. I just made the extension work for me on SeaMonkey and have what I want.

Comment 18

[Alan]

This 12-year-old bug is still a nasty problem. I just had Firefox lose an unresumable download because the machine went to sleep. I was very far into it, too. :(

Comment 19

[emre.tkg]

Is this still on a to-fix list? Or has it been abandoned? Firefox still seems to have the same behaviour.

Comment 20

[Alan]

(In reply to emre.tkg from comment #19)
> Is this still on a to-fix list? Or has it been abandoned?

This bug is 12 years old and has no champion trying to fix it, so it's probably best to expect it to not get fixed in the foreseeable future.

Comment 21

[Sledge Hammer]

This is still a very annoying issue on latest Windows 10 with FireFox 75.

IMHO an option should be added to FireFox download settings to enable a standby block WHILE downloads are running. It's just such a trivial requirement that when a user triggers a download, he certainly does not want that it is terminated just because PC goes to sleep.

Similiar to blocking standby while watching streams it should be possible to block standby while downloads are active. Please can somebody increase the priority of this tickets?

Note: Everybody knows that there are external ways to avoid this, but it should be responsibility of FireFox to ensure downloads are finished.

Comment 22

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:mak, could you have a look please?
For more information, please visit auto_nag documentation.