browser.download.manager.quitBehavior has no effect in FF 52.2.0

RESOLVED WONTFIX

Status

()

Toolkit
Downloads API
RESOLVED WONTFIX
9 months ago
9 months ago

People

(Reporter: j1095945, Unassigned)

Tracking

52 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 months ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170613225334

Steps to reproduce:

0. use firefox 52.2.0 on debian (or another gnu/linux distro where ctrl-q quits immediately)
1. in about:config, set browser.download.manager.quitBehavior to 2 (QUIT_AND_CANCEL) as in https://dxr.mozilla.org/mozilla-release/source/toolkit/components/downloads/nsDownloadManager.h#212
2. download some file that takes a while
3. press ctrl-q while the download is still running


Actual results:

confirmation dialogue "do you want to cancel 1 running download" appears


Expected results:

browser should quit immediately without asking

Updated

9 months ago
Component: Untriaged → Downloads API
Product: Firefox → Toolkit

Comment 1

9 months ago
(In reply to j1095945 from comment #0)
> https://dxr.mozilla.org/mozilla-release/source/toolkit/components/downloads/nsDownloadManager.h#212

This was dead code and has now been removed, as the link shows. We don't plan to add this preference back.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 months ago
Resolution: --- → WONTFIX
(Reporter)

Comment 2

9 months ago
(In reply to :Paolo Amadini from comment #1)
> We don't plan to add this preference back.

sad.

I assume there is no other mechanism to override that confirmation dialogue?

If anyone else stumbles upon this:
Setting the eForceQuit flag on shutdown request with the quit() method of nsIAppStartup does not solve this, the dialogue still appears.
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIAppStartup
(In reply to :Paolo Amadini from comment #1)
> (In reply to j1095945 from comment #0)
> > https://dxr.mozilla.org/mozilla-release/source/toolkit/components/downloads/nsDownloadManager.h#212
> 
> This was dead code and has now been removed, as the link shows. We don't
> plan to add this preference back.

Dead code in which sense? As it looks like at least for automation this is a major issue in not being able to close the browser until the download has been finished. I do not see a workaround either.

So how should automation initiate a normal application shutdown / restart if there is no way to disable this modal dialog? Explicitly having to check for this modal dialog is nasty.
Blocks: 1388041
Flags: needinfo?(kohei.yoshino)

Comment 4

9 months ago
(In reply to Henrik Skupin (:whimboo) from comment #3)
> Dead code in which sense?

It hasn't been running in production since we migrated to the JavaScript API for Downloads.

> So how should automation initiate a normal application shutdown / restart if
> there is no way to disable this modal dialog? Explicitly having to check for
> this modal dialog is nasty.

If we have a test in Continuous Integration that leaves a dangling download, the test should wait for the download to complete or cancel it explicitly before closing the browser. I don't think we should leave a paused download with associated temporary files without failing the test.

If the test is specifically designed for this restart scenario, it should verify that the dialog is shown in the first place and it should have a way to answer it, maybe even verifying the effect of different answers.
Oh, that makes sense! I should have thought about that. Thanks.
Flags: needinfo?(kohei.yoshino)
You need to log in before you can comment on or make changes to this bug.