1736749 - Fix browser_download_open_with_internal_handler.js to pass when download improvements are enabled

Status: RESOLVED FIXED

(Firefox :: Downloads Panel, task, P1)

Description

[Sam Foster [:sfoster] (he/him)]

This test fails when browser.download.improvements_to_download_panel is set to true. It shouldn't.

Comment 1

[Sam Foster [:sfoster] (he/him)]

This is another one of those tests that details some very explicit steps and expectations for what should happen when we load some file with some Content-Type. The browser.download.improvements_to_download_panel pref changes the outcomes.

I'm not sure if we need to rework each task to run those steps with both [false, true] values for the preference and assert on the expected things happening. Or set alwaysAsk to true so we can verify the existing flows still work correctly when the user has made that choice (which is currently implicit and might become untested otherwise)

Do you have a preference :Gijs? It feels like if I rework the test to expect the new behavior that is coverage we have elsewhere and we might lose something specific this test was written for. But there's not much useful context in bug 773942 that landed these tests so I'm not sure.

Comment 2

[:Gijs (he/him)]

(In reply to Sam Foster [:sfoster] (he/him) from comment #1)

This is another one of those tests that details some very explicit steps and expectations for what should happen when we load some file with some Content-Type. The browser.download.improvements_to_download_panel pref changes the outcomes.

I'm not sure if we need to rework each task to run those steps with both [false, true] values for the preference and assert on the expected things happening. Or set alwaysAsk to true so we can verify the existing flows still work correctly when the user has made that choice (which is currently implicit and might become untested otherwise)

Do you have a preference :Gijs? It feels like if I rework the test to expect the new behavior that is coverage we have elsewhere and we might lose something specific this test was written for. But there's not much useful context in bug 773942 that landed these tests so I'm not sure.

AFAICT all of these tests are specifically around how the dialog behaves wrt "open internally", so I think setting things to alwaysAsk for that test is fine. We can check the right PDF.js behaviour for the improvements+always-handle-internally combination elsewhere once we have finalized it; I think we'll need to do some testing "in the wild" once the pref has flipped to see if we can get away with e.g. showing Content-Disposition: attachment pdfs inline.

Comment 3

[Sam Foster [:sfoster] (he/him)]

Attachment: Bug 1736749 - ensure we alwaysAskBeforeHandling downloads in browser_download_open_with_internal_handler.js to verify unknown-content-type dialog behavior when download improvements are flipped on. r?Gijs

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8a5b2ab6e9a6
ensure we alwaysAskBeforeHandling downloads in browser_download_open_with_internal_handler.js to verify unknown-content-type dialog behavior when download improvements are flipped on. r=Gijs

Comment 5

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/8a5b2ab6e9a6