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

Status: RESOLVED WONTFIX

(Toolkit :: Downloads API, defect)

Description

[j1095945]

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

Comment 1

[:Paolo Amadini]

(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.

Comment 2

[j1095945]

(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

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(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.

Comment 4

[:Paolo Amadini]

(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.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Oh, that makes sense! I should have thought about that. Thanks.