Description of problem: With the Gnome automatic suspend, that is by default set to 20 minutes, Firefox does not hold the lock to block suspending the machine. This would be normal behaviour, but when there are downloads going on, it should block the machine from suspending, in order not to interrupt the downloads. Many users download stuff while not working with their machines and this behaviour is annoying to them. Version-Release number of selected component (if applicable): firefox.x86_64 59.0.1-1.fc28 How reproducible: Always Steps to Reproduce: 1. Start a download in Firefox 2. Leave the computer for 20 minutes. 3. Come back and find it suspended Expected results: All downloads should be finished before the computer suspends. Additional info: To be able to reproduce this problem, you can set the automatic suspend time to a shorter span, so that you do not have to wait so long. gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 120
I am nominating this as a PrioritizedBug, because it can affect our users in a negative way, but such functionality does not block the release.
Uff...can you give me an example of any application (which downloads any data) with such behavior? Anyway, this report needs to be uplifted at bugzilla.mozilla.org.
Well, the problem is caused by the Gnome setting that suspends the computer after 20 minutes of inactivity. Users can change the value using the GUI tools between 15 minutes and 120 minutes or switch it off completely. However, if they don't the default 20 minutes can surprise them quite terribly because their computer will suspend during activities that are unknown to system such as downloading in Firefox. For example, the DNF informs Gnome about installation in progress, so the computer never suspends during DNF installing packages. I would expect the same behaviour from Firefox, because downloading should be an activity that users want to finish first, before the computer suspens, for example many users download over the night, which now is impossible. It does not look like the Gnome team is going to change this default settings, so the only thing to prevent this to happen, is to make Firefox able to tell Gnome that there is activity going on and to stop the countdown to suspend. Similar problem is being discussed in bug 1558485.
It's not easy to solve that on Firefox side, I don't expect the fix sooner that with Firefox 61/62. I suggest to fix that on gnome side before we have a Firefox fix.
There's already a bug for Windows: https://bugzilla.mozilla.org/show_bug.cgi?id=356762 I don't expect this is going to be fixed on Firefox side soon.
Filed as https://bugzilla.mozilla.org/show_bug.cgi?id=1449136
Martin, do you know _how_ Firefox could take out the proper inhibitor? We'd want it to prevent idle suspend, but not if, for example, a laptop lid is closed. It'd probably be helpful to put pointers to the docs for how to do that in the upstream bug -- maybe we can find someone from GNOME or systemd to help with that (the pointers, if not the actual code)?
(In reply to Matthew Miller from comment #7) > Martin, do you know _how_ Firefox could take out the proper inhibitor? We'd > want it to prevent idle suspend, but not if, for example, a laptop lid is > closed. > > It'd probably be helpful to put pointers to the docs for how to do that in > the upstream bug -- maybe we can find someone from GNOME or systemd to help > with that (the pointers, if not the actual code)? I have no idea how to implement that on Firefox side. You can start with the same bug filed for Firefox/Windows: https://bugzilla.mozilla.org/show_bug.cgi?id=356762 There's also a patch included for Windows back end, It may be adapted for Linux.
Also, I don't think this is a priority bug - it's 12 years old, with 7 votes only. The add-on used for that (before WebExtensions) has ~800 downloads since for instance AddBlock has about 2mil downloads. This is not something I want to spend time on.
It's become higher priority for us because of the change in GNOME behavior. ACK to you not wanting to spend time on it, though. My proposal is to make sure that upstream has the information they need.
The bug has not been approved as a Prioritized one. Please consider to re-propose the bug as Prioritized if the GNOME idle suspend feature is reintroduced.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.