Closed Bug 1165558 Opened 6 years ago Closed 6 years ago
e10s - when downloading a pdf, Firefox automatically saves; no choice/dialogue box for opening in an application (i
.e . Acrobat)
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:40.0) Gecko/20100101 Firefox/40.0 Build ID: 20150515091916 Steps to reproduce: From within this web page: http://www.unocha.org/data-and-trends-2014/downloads/World%20Humanitarian%20Data%20and%20Trends%202014.pdf I clicked on the download button (upper right corner between the"Print" button and the "Current view" button Actual results: The pdf downloaded immediately to the default directory Expected results: The usual Firefox window should have popped up: "What should Firefox do with this file? Open with (picklist with apps) Save file" This choice was not given, i.e. it was not possible to open directly in Acrobat.
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:41.0) Gecko/20100101 Firefox/41.0 Build ID: 20150515084717 Steps to reproduce: 1. about:preferences#applications → PDF set to Preview in Firefox. 2. http://www.unocha.org/data-and-trends-2014/downloads/World%20Humanitarian%20Data%20and%20Trends%202014.pdf 3. Click the Download button in the PDF Viewer's toolbar. Actual results: The file is saved to the default download folder, if “Save files to” is selected under about:preferences#general A prompt to choose the location and file name appears, if “Always ask me where to save files” is selected under about:preferences#general Expected results: In either case, Firefox's “You have chosen to open…” dialog should pop up, with a choice of opening the file in a particular application, or saving it. Notes: Wasn't there an “Open with a different viewer” button at some point? Does it only show when Firefox detects a problem with the rendering, or is it completely gone now?
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
I was able to reproduce this issue on Firefox 42.0a1 (2015-07-26) and Firefox 41.0a2 (2015-07-26) under Windows 8.1 32-bit, Ubuntu 13.10 64-bit and Mac OS X 10.10.4. - This issue is also reproducible with Firefox 35.0a1 from 2014-10-01 - This issue is e10s specific.
If we're passed a content disposition hint we can still return a content disposition.
Attachment #8669240 - Flags: review?(josh)
Comment on attachment 8669240 [details] [diff] [review] Patch v1 Review of attachment 8669240 [details] [diff] [review]: ----------------------------------------------------------------- This is code that I haven't touched in a very long time, and rereading all this stuff to figure out what is means is a low priority for me. If you're willing to wait then I can try to review it at some point, but it feels like there's probably a better candidate for this than me.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago → 6 years ago
Resolution: --- → INVALID
This is a reproducible issue that has someone working on it.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Comment on attachment 8669240 [details] [diff] [review] Patch v1 bz agreed to review this.
Attachment #8669240 - Flags: review?(josh) → review?(bzbarsky)
Attachment #8670041 - Flags: review?(bzbarsky)
Status: REOPENED → ASSIGNED
Comment on attachment 8669240 [details] [diff] [review] Patch v1 It's not obvious to me where this UINT32_MAX value would come from, not least because I can't figure out who really allocates these objects. r=me, but please document the source of that value.
Attachment #8669240 - Flags: review?(bzbarsky) → review+
Comment on attachment 8670041 [details] [diff] [review] Enable this test since it passes r=me
Attachment #8670041 - Flags: review?(bzbarsky) → review+
Backed out in a6f277178c7b for making the bug 1016737 leak-until-shutdown very very frequent on Windows.
https://hg.mozilla.org/integration/mozilla-inbound/rev/6d77482da8dd6d143f9e2ecdeaf0b79a51047749 Bug 1165558 - Return valid dispositions even if there wasn't a header. r=bz
I have reproduced this bug with Firefox 41.0a1 (Build: 20150516030207)on windows 8.1 pro 64-bit with the instructions from comment 0 and comment 1 . Verified as fixed with Latest Firefox Aurora 44.0a2 (Build ID: 20151029045227) Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0 Verified as fixed with Latest Firefox Nightly 45.0a1 (Build ID: 20151030030236) Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Reproduced this bug on Nightly 41.0a1 (2015-05-16); (Build ID: 20150516030207) in Linux,64 bit This Bug is now verified as fixed on Latest Firefox Dev Edition 44.0a2 (2015-10-29) Build ID: 20151029045227 User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0 As it is also verified on Windows (Comment 15), Marking it as verified!
As it is verified on both Windows (Comment 15) and Linux (Comment 16), marking it as verified. [testday-20151030]
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.