Fix browser_download_open_with_internal_handler.js to pass when download improvements are enabled
Categories
(Firefox :: Downloads Panel, task, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox95 | --- | fixed |
People
(Reporter: sfoster, Assigned: sfoster)
References
Details
(Whiteboard: [fidefe-mr11-downloads])
Attachments
(1 file)
This test fails when browser.download.improvements_to_download_panel is set to true. It shouldn't.
|
||
Updated•3 years ago
|
|
Assignee | |
Comment 1•3 years ago
|
||
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•3 years ago
|
||
(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_panelpref 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
alwaysAskto 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.
|
|
Assignee | |
Comment 3•3 years ago
|
||
|
||
Comment 5•3 years ago
|
||
| bugherder | ||
Description
•