Closed Bug 1756980 Opened 2 years ago Closed 2 years ago

PDF downloads (`<a>` with `download` attribute, or Content-Disposition: attachment) opens in the same tab rather than as a download

Categories

(Firefox :: File Handling, defect, P2)

Product:
Firefox
Component:
File Handling
Version:
Firefox 98
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
101 Branch
Tracking Flags:
Tracking Status
firefox101 --- verified

People

(Reporter: whymarrh.whitby, Assigned: nika)

References

Details

(Whiteboard: [fidefe-2022-downloads-followup])

Attachments

(4 files)

Bug 1756980 - Part 1: Redirect internally-handled attachment loads into new tabs, r=gijs!,smaug!
48 bytes, text/x-phabricator-request
Details | Review
Bug 1756980 - Part 2: Update tests for new download behaviour, r=gijs!
48 bytes, text/x-phabricator-request
Details | Review
Bug 1756980 - Part 3: Clarify "process switch" parameters in DocumentLoadListener, r=smaug!
48 bytes, text/x-phabricator-request
Details | Review
Example of the kind of interface this is breaking.
1.26 MB, image/png
Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.3 Safari/605.1.15

Steps to reproduce:

This bug is visible in the 1Password signup flow:¹

  • Create an account, verify the email, skip the payment screen
  • On the Save your Emergency Kit screen, click Download PDF

¹ Test using https://start.b5test.com/sign-up/plan

Actual results:

The PDF is opened in the same tab, discarding the page state.

This fails on the latest Nightly, at the time of writing: 99.0a1 (2022-02-23) (64-bit) on macOS

Expected results:

Firefox should prompt to Open/Save the PDF file, keeping the existing tab state.

This works as expected on the latest stable release: 97.0.1 (64-bit) on macOS

This is also reproducible using PDFKit's example: https://pdfkit.org/demo/browser.html

Swap the default example for the following:

var doc = new PDFDocument();
var stream = doc.pipe(blobStream());

doc.fontSize(25).text('Here is some vector graphics...', 100, 80);

doc
  .save()
  .moveTo(100, 150)
  .lineTo(100, 250)
  .lineTo(200, 250)
  .fill('#FF3300');

doc.circle(280, 200, 50).fill('#6600FF');

doc
  .scale(0.6)
  .translate(470, 130)
  .path('M 250,75 L 323,301 131,161 369,161 177,301 z')
  .fill('red', 'even-odd')
  .restore();

doc
  .text('And here is some wraaapped text...', 100, 300)
  .font('Times-Roman', 13)
  .moveDown()
  .text(lorem, {
    width: 412,
    align: 'justify',
    indent: 30,
    columns: 2,
    height: 300,
    ellipsis: true
  });

doc.end();
stream.on('finish', function() {
  var url = stream.toBlobURL('application/pdf');
  var btn = document.createElement('a');
  btn.innerText = "Download PDF";
  btn.setAttribute("download", "file.pdf"); // Download attribute
  btn.setAttribute("href", url); // PDF Blob URL
  iframe.parentElement.appendChild(btn);
});

This will add a "Download PDF" link to the bottom of the page, that loads the PDF into the current tab, rather than prompting to save it.

The download link works as expected in Firefox stable, but not in the latest Nightly.

Also reproducible on the latest Firefox Beta: 98.0b8 (64-bit) on Windows and macOS

Version: Firefox 99 → Firefox 98

The Bugbug bot thinks this bug should belong to the 'Firefox::Downloads Panel' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Downloads Panel

File Handling is probably a better place for this.

Component: Downloads Panel → File Handling

(In reply to Whymarrh Whitby from comment #1)

This will add a "Download PDF" link to the bottom of the page, that loads the PDF into the current tab, rather than prompting to save it.

This is expected behaviour for 98 and above. PDFs are set to open in Firefox by default, and in earlier versions that didn't work properly (bug 453455). Users can save the PDF just fine using the relevant button in PDF.js .

It's not clear to me why this is a problem here - presumably the "back" button still works and just takes you back to the sign-in flow? If it doesn't, that's likely an issue your site could fix.

If you change the mimetype you give the Blob to application/octet-stream or target the link whose href you assign to an iframe within your page, I think you'll get the previous behaviour back - though tbh that seems user-hostile to me. After all, when the PDF is viewed directly users can choose to save or print, or copy-paste stuff into another doc, and it'll be fewer clicks than having to make choices about what to do with the PDF file...

It's not clear to me why this is a problem here

This behaviour, especially with the presence of the download attribute is very different now than it is in other browsers. Shouldn't the download attribute win in this case?

(In reply to Whymarrh Whitby from comment #6)

It's not clear to me why this is a problem here

This behaviour, especially with the presence of the download attribute is very different now than it is in other browsers. Shouldn't the download attribute win in this case?

When the download attribute applies, it is treated the same way as a Content-Disposition: attachment header sent by the server. As I noted before, per bug 453455, we think the user's preferences should win over what the server says - irrespective of whether the user has indicated they want the PDFs to open in an external app (Acrobat or w/e), automatically save to disk, or opening in Firefox. For the latter case, we open the file direct from the server, rather than first saving to disk, which helps preserve the URL of the PDF (though I guess that's less useful for blob URLs, those are probably a minority), cf bug 1689666. Users can still save the PDF to disk from within the PDF viewer UI, if they want to do that.

I don't think the fact that other browsers don't do this, on its own, is a good enough reason not to provide the users with what they've indicated they want. I think broadly, our thinking is that, given Firefox can display the PDF document, in the general case it is more useful to show the document first. Then users can make their own choice about whether they want that document permanently copied to their machine, based on the contents (rather than the previous flow, where asking gives you the filename but no other context, and either way it isn't possible to see the document without saving it to disk permanently).

Molly, Marco, does this make sense (and should we close this as wontfix?) or am I missing something here?

(I'll note that even if we do decide to alter Firefox behaviour in some way (perhaps specific to blob URLs, or the download attribute, or something else?) then it's unlikely to happen for Firefox 98 given that we're less than a week away from its general release, so if this really breaks workflows (I still don't really understand why!) then I would repeat my suggestions in comment #5 around how the website can still impact this behaviour)

Flags: needinfo?(mhowell)
Flags: needinfo?(mak)

For context on our situation—as I'm sure there are similar situations out there—we do want to ensure the file is saved to the user's machine. It is crucial that the file isn't just opened and navigated away from, as it contains information that is generated on-device. While I understand how forcing a download might appear "user-hostile", there are a large number of users who might see the document opened and not understand that they need to save it.

(In reply to Whymarrh Whitby from comment #8)

For context on our situation—as I'm sure there are similar situations out there—we do want to ensure the file is saved to the user's machine. It is crucial that the file isn't just opened and navigated away from, as it contains information that is generated on-device. While I understand how forcing a download might appear "user-hostile", there are a large number of users who might see the document opened and not understand that they need to save it.

Thanks for the added context. This isn't really the core issue here, but for what it's worth, I don't think using technical means to force the document to end up in the user's download folder is a good way of making them understand the value of the document, or ensuring that they take appropriate actions regarding that document.

Before 98, by default for this PDF the user would get a dialog asking if they wanted to open in firefox, open with another app, or save. If they pick "open in firefox" (the default!) or "open with [acrobat/edge/whatever]" and were on Windows or Linux, the file would be saved in the temp directory, and deleted once the browser and/or private browsing session in the browser was ended. As a result, your goal of ensuring permanent storage would still not be accomplished. On macOS, lost in a pile of other PDFs in the default downloads folder, I am also not convinced users would be able to find it back when needed...

If it's important the user saves the document somewhere specific, I recommend communicating that more clearly to the user.

(In reply to :Gijs (he/him) from comment #7)

When the download attribute applies, it is treated the same way as a Content-Disposition: attachment header sent by the server. As I noted before, per bug 453455, we think the user's preferences should win over what the server says - irrespective of whether the user has indicated they want the PDFs to open in an external app (Acrobat or w/e), automatically save to disk, or opening in Firefox.

In general I agree that for now the current behavior is ok, and we should continue monitoring feedback.
There's just a couple concerns that have been rised, and I can sympathize with some of it:

  1. not coherent with other browsers. Of course the user doesn't know what happens on that site, since it's server side, unless they commonly use that site in another browser. Then migrating to Firefox would break expectations on that site.
  2. The part about respecting the user's will won't work when the server uses octect-stream, that's not something you can set a preference for. Thus we're not providing a predictable experience anyway, the pdf may still either be downloaded or shown without the user knowing in advance. We just moved the needle a little bit more towards showing.

That said, I don't think both are critical concerns, there's workarounds or alternative workflows for most of this, like you said the pdf reader allows to download.

Flags: needinfo?(mak)

I concur with Gijs and Marco on this, both in the matter of the user setting overriding the server indication being the right thing to do, as well as on the question of automatically downloading this file maybe not really having the intended effect; I've seen a lot of users' download folders over the years, and a lot of them are not very well kept, including mine I'm ashamed to admit.

Flags: needinfo?(mhowell)

This was a jarring change to encounter today (after updating to Firefox build 98.0), when our application was working as expected with blob URLs given a "download" attribute in iterations of build 97.0 (as seen during testing earlier in the day). The Mozilla documentation (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#attributes) still reflects the previously established behavior which confused matters further.

(In reply to Mike from comment #12)

This was a jarring change to encounter today (after updating to Firefox build 98.0), when our application was working as expected with blob URLs given a "download" attribute in iterations of build 97.0 (as seen during testing earlier in the day).

I'm sorry about the inconvenience.

The Mozilla documentation (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#attributes) still reflects the previously established behavior which confused matters further.

The documentation covers the behaviour of <a download> in general (it's only "Mozilla" documentation in the sense that we host the docs and employ people who work on the site, but the site is web-focused, not Mozilla-focused), and is focused on web developers, not on documenting Firefox's user-facing behaviour. I don't think focusing on the previous wording there is super helpful - it apparently said "prompts the user to download", but e.g. Chrome has never prompted for these types of links, and instead always just starts a download...

I've set up a PR (all the content is on github! You can help too!) to get some of the wording updated, https://github.com/mdn/content/commit/5161e0dead1b04940560b5e45f17f2ce3ebfae08 - it's not showing up for me yet on the actual docs site, but it will eventually - I'm not sure how caching/deployment works for that site so ymmv.

But what with applcations that hava state?
When user click link to download PDF, he will lose state of application. In this situation user think that it is problem with application not with settings of him FIREFOX browser. I think that default option for "Content-type: attachement" should be always ask. And then user can decide if he want download or only opne in browser. The other problem is that header "Content-type: attachement; filename='file.pdf'" is ignored so we can not decide which name for file will be present.

(In reply to Kamil from comment #14)

But what with applcations that hava state?

Those applications should be saving state and/or using beforeunload anyway, as "clicking a link to a PDF" is hardly the only way they can be interrupted (other navigations, the tab being closed, the browser quitting, the OS restarting for updates... it's a pretty long list).

I think that default option for "Content-type: attachement" should be always ask.

What the default is is orthogonal - no other browser I'm aware of defaults to "always ask", they all save to disk. (Safari has a per-site permission for downloads generally but I'm pretty sure everyone agrees that a modal prompt that offers no details at all about the download and just asks whether downloads in general should be allowed for that site is not a good user experience - plus after you allow them, any subsequent downloads don't ask you anything). This bug is purely about whether we end up replacing the tab content.

There is no way to address bug 453455 (which, before we fixed it, was the most-frequently-duplicated Firefox front-end bug in our entire bug tracker) and keep treating Content-Disposition: attachment as somehow "special". We had to do some extra work for PDFs, and in theory we could undo that and then we'd treat Content-Disposition: attachment as special just for PDFs, which didn't seem like it was likely to make any sense to users.

The other problem is that header "Content-type: attachement; filename='file.pdf'" is ignored so we can not decide which name for file will be present.

Feel free to file a separate bug about that; I don't know how easy it will be to fix, but I do agree that that is not ideal.

The flip side of this change is that for public links, this makes it a lot easier for users to copy/share/bookmark links (ie we fixed bug 1689666 by doing it this way) to these PDFs, which seems valuable (though as said not for the original case from comment 0 using blob URLs).

(In reply to :Gijs (he/him) from comment #15)
Thanks for the answer. I understand your motivatioin and user friendly interface, but could we have chance to open that links in new tab.
For example attribute target="blank" could bo present in <a> tag and it will open file in new tab?
I tried this and now attribute "target" is also ignored.

In above comment i mean situation when we hve attribute "target=''blank" with "download" attribute together. In this situation it is not working.

(In reply to Kamil from comment #17)

In above comment i mean situation when we hve attribute "target=''blank" with "download" attribute together. In this situation it is not working.

This is a little surprising to me - would you mind filing a separate bug about it? Then we can investigate in more detail. Even better if you have a testcase you can point to.

Flags: needinfo?(ksiwak2e)

(In reply to :Gijs (he/him) from comment #18)

This is a little surprising to me - would you mind filing a separate bug about it? Then we can investigate in more detail. Even better if you have a testcase you can point to.

I tried to reproduce it and I found where is problem. It is problem with domain. If PDF is serving from other domain everything is ok.
But when PDF is localized in same domain as current page in browser then link will open PDF in same Tab ang ignoring target="blank" attribute.

It is open link in new tab.

<a href="http://other-domian/file.pdf" target="blank" download="File.pdf"">Download FILE</a>

These examles open links in same tab

<a href="http://same-domian/file.pdf" target="blank" download="File.pdf"">Download FILE</a>
<a href="documents/file.pdf" target="blank" download="File.pdf"">Download FILE</a>

Flags: needinfo?(ksiwak2e)

We ran into the same problem.
In our app, if the page is abandoned for the opening of the pdf, the process in which the user was participating is reset.
Specifying target='blank', in order to open the pdf NOT in the same page, can be a valid solution in our case.

(In reply to Kamil from comment #19)

(In reply to :Gijs (he/him) from comment #18)

This is a little surprising to me - would you mind filing a separate bug about it? Then we can investigate in more detail. Even better if you have a testcase you can point to.

I tried to reproduce it and I found where is problem. It is problem with domain. If PDF is serving from other domain everything is ok.
But when PDF is localized in same domain as current page in browser then link will open PDF in same Tab ang ignoring target="blank" attribute.

Please can you still file a separate bug about this? It's not clear to me that fixing this is going to be useful for the original bug reporter, so I'd rather we deal with it separately, rather than ending up marking this bug "fixed" when we land a patch to address the target=_blank case, without actually fixing it for the reporter of this bug. :-)

Flags: needinfo?(ksiwak2e)

(In reply to :Gijs (he/him) from comment #18)

I created new BUG for this:
https://bugzilla.mozilla.org/show_bug.cgi?id=1759916

Flags: needinfo?(ksiwak2e)

The severity field is not set for this bug.
:Gijs, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(gijskruitbosch+bugs)

This completely destroyed our user experience. The backend server is generating PDF files, and it can take up to 5 seconds: not enough to go for an asynchronous generation model. The user would get stuck on a blob URL instead of having visual indicators that hos action was occurring.

We now have to force the mimetype to be application/octet-stream for the blob to get downloaded - but firefox will still open it in a new tab once downloaded (I guess the mimetype gets corrected), forcing the user to close it to come back to the original page (or worse, save it a second time).

As much as I understand the reasoning behind this, this is a breaking change, so many applications are relying on this behavior.

Summary: PDF Blob download link opens in the same tab rather than as a download → PDF downloads (`<a>` with `download` attribute, or Content-Disposition: attachment) opens in the same tab rather than as a download

IMHO:

  1. I guess there might be quite some websites that rely on the <98 behavior (and similar behavior in other browsers).
    For those who do not save their state properly it will also be a very poor user experience if the user comes back from the pdf.
    You might say that this is the responsibility of those web developers, but nevertheless, the status quo is a bad user experience for the users at such websites.

  2. It is no longer possible to explicitely offer a download.
    Before: user clicks link -> pdf is downloaded or the user is asked where to download -> after downloading the user is still at the website (ideally 1 click)
    Today: user clicks link -> pdf is opened -> user has to press save (and he has to know that he should do and where to find the possibility to save) -> user has to go back (4 clicks!)

Hi.

An additional issue about ignoring the "download" attribute arise when an application wants to provide a PDF download as a blob: url. The provided name is completely ignored, causing the download button to present a file named "document.pdf". This is also not good for user experience.

See Also: → 1759916

(In reply to :Gijs (he/him) from comment #5)

(In reply to Whymarrh Whitby from comment #1)

This will add a "Download PDF" link to the bottom of the page, that loads the PDF into the current tab, rather than prompting to save it.

This is expected behaviour for 98 and above. PDFs are set to open in Firefox by default, and in earlier versions that didn't work properly (bug 453455). Users can save the PDF just fine using the relevant button in PDF.js .

It's not clear to me why this is a problem here - presumably the "back" button still works and just takes you back to the sign-in flow? If it doesn't, that's likely an issue your site could fix.

If you change the mimetype you give the Blob to application/octet-stream or target the link whose href you assign to an iframe within your page, I think you'll get the previous behaviour back - though tbh that seems user-hostile to me. After all, when the PDF is viewed directly users can choose to save or print, or copy-paste stuff into another doc, and it'll be fewer clicks than having to make choices about what to do with the PDF file...

I think this behavior is user hostile, since it forcibly logout users who are already logged in webapp where session is done over a websocket connection.

This also happens on WhatsApp web now. PDF files are opened in the same tab, although pressing the back button does re-logins the users.
But I think this shows that this behavior is not expected.

This also happens on WhatsApp web now. PDF files are opened in the same tab, although pressing the back button does re-logins the users.
But I think this shows that this behavior is not expected.

Threema Web is affected as well, and we have already received a few support requests from confused users as a consequence. Threema Web is a SPA where a connection with the target device (usually a smartphone) is established over WebRTC data channels. PDF files (as part of a file message) are transferred from the phone to the browser memory, and then downloaded as a Blob instance. By ignoring the download attribute and opening a PDF file (which the user explicitly wanted to download) in the same tab, the connection is terminated. First of all, this is unexpected for the user (the user explicitly clicked on a "save" icon), secondly even when using the back navigation button, the connection to the device is dead and needs to be re-established. If there was previous unsubmitted content on the page (e.g. a message draft that was not yet submitted), that data is gone.

I understand the thinking behind this change, but I suspect it wasn't thought through and should be reverted. In the case of Threema Web, as a Firefox-specific workaround, we will probably change the blob media type for PDFs to application/octet-stream before downloading. That is not nice because some semantics are lost, and additionally the PDF is still opened immediately in a new tab (which makes saving multiple PDFs annoying), but at least the users don't lose their tab state just because they downloaded a PDF.

I got he exact same problem, with PDF files getting opened in the same tab since the last update.
This is extremely annoying. A lot of websites now are complex SPAs, and we can't just press the "back". The state is lost once you quit the page.
For example, if I click a PDF attachment in my ProtonMail inbox, it closes the webmail!
The default behavior should be to open the file in a new tab. And I often can't do a wheel click to open the link in a new tab, since the call comes from a window.open().

I set-up my browser to "Always Ask" for PDF files, in order to avoid FF crashing my current tab. But now, there is two new problems :

  • I can no longer choose the option "open with firefox"
  • the PDF-in-Iframe feature is broken. If I go on a webpage with an embedded PDF file, the iframe stays blank and I get a download popup

This is really problematic for working. I have now switched to Chromium in the wait for this bug to be fixed.

As already noted: browser back is no solution in SPAs.

In Germany, it is a legal requirement that interested parties must be offered the complete contract documents for download before taking out insurance online and the customer must confirm that they have received them. In our SPA applications, this means that the user loses the SPA session with a browser back and no contract can be concluded.

As a quick fix, we've set up a landing page that explains to Firefox 98 users what setting they need to change (or alternatively use other browsers).
https://www.cosmosdirekt.de/browser-firefox/

A release where we changed the mime type to "application/octet-stream" (which is not a good solution) is currently being prepared.

So please: Accept that sometimes the application knows better what needs to be done with a download.

(In reply to Leonhard Zech from comment #32)

So please: Accept that sometimes the application knows better what needs to be done with a download.

I agree, ultimately this is what it comes down to. Having this behaviour be configurable seems great but there are many contexts where the application knows something that the UA/Firefox might not and it should be able to force a download when appropriate.

(In reply to :Gijs (he/him) from comment #15)

(In reply to Kamil from comment #14)

But what with applcations that hava state?

Those applications should be saving state and/or using beforeunload anyway, as "clicking a link to a PDF" is hardly the only way they can be interrupted (other navigations, the tab being closed, the browser quitting, the OS restarting for updates... it's a pretty long list).

This, unfortunately, might be a bit reductive. I don't think it's a coincidence that some of the examples in the thread here—ProtonMail, Threema Web, WhatsApp, and 1Password—are all applications where some of the state may be kept in memory intentionally for security reasons. It isn't quite as simple as "save your state and use the back button." Additionally, equating the application itself having a PDF it controls and wants to download with the external ways that the application can be interrupted doesn't quite seem fair.

Another example that illustrates the problem of a user-agent overriding application logic: Let's assume you're using a video conference application that allows sharing documents to other call participants. You receive a PDF, you want to download it, and suddenly you're disconnected from the call. If it's a call that requires confirmation before joining, you can't even just navigate back and immediately be re-joined, instead the call admin needs to let you in first, causing a disruption of the conversation. (In practice, once that happened a few times, it would probably be followed by a slightly annoyed recommendation from your peers to stop using Firefox 🙁)

Depends on: 1759916
See Also: 1759916 →

we should investigate this and Bug 1759916 at the same time to see if both can be addressed by the same change. S2 since this is breaking sites.

Severity: -- → S2
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
Whiteboard: [fidefe-2022-downloads-followup]
Flags: needinfo?(gijskruitbosch+bugs)

Nika, if we wanted the PDF.js stream converter to redirect to a new tab (in some cases), what would be the easiest way of making that happen? This would be after the channel and loadinfo get constructed and pick a target browsing context...

Flags: needinfo?(nika)

I do agree with comment #33, it's a major pain on our side due to the necessity of having a "guaranteed" download by law.

As it stands now, there is now way of forcing a download of PDF document and not leaving the shown page, right?

Is there already some kind of alternative on the horizon?

Furthermore, fixing that "download" attribute is breaking the UI (always opening a in same tab) would be at least something to go with.

(In reply to Bernnt from comment #37)

I do agree with comment #33, it's a major pain on our side due to the necessity of having a "guaranteed" download by law.

As it stands now, there is now way of forcing a download of PDF document and not leaving the shown page, right?

There is a way for now: if you force the mimetype of the downloaded file (either server-side, or client-side if you create a blob) to application/octet-stream, it will save the file and then open it in a new tab as requested.

Still a suboptimal experience for users, but that would at least fit your legal requirements somehow.

Self-assigning for now, as I have some local WIP patches to re-assign the load into a new tab when handling Content-Disposition: attachment internally. It's going to be quite messy as we need to handle this when the navigation is already in-flight.

(In reply to Marco Bonardo [:mak] from comment #35)

we should investigate this and Bug 1759916 at the same time to see if both can be addressed by the same change. S2 since this is breaking sites.

The changes I have locally don't specifically change this behaviour (The "download" attribute always overrides the "target" attribute right now due to the expectation internally that the download is handled by an external program and won't render anything), however they do make the download attribute always act similar to a target="blank" rel="noopener" load if they're handled internally. I don't think we want to support other target attributes impacting downloads, such as named targets or targets like "_top".

Assignee: nobody → nika
Flags: needinfo?(nika)
Depends on: 1710941

This patch changes how we handle document loads which are being handled
internally but have Content-Disposition: attachment specified at the
DocumentLoadListener layer. This was done as process switching is
currently the only place during a load where we can change the target
BrowsingContext which the load will complete in.

The only situation where we should currently continue to deliver a
successful request to the default content-viewer despite
Content-Disposition: attachment being specified is when we choose to
handle a downloaded PDF internally, so this shouldn't impact other
cases.

The change is handled by forcing a process switch under the hood, and
opening a new browser window asynchronously to handle the process
switch, similar to how object and embed load upgrades are handled. This
is done using nsIBrowserDOMWindow to attempt to respect the user's
window opening preferences.

A small change to browser.js was also made to try to encourage the new
tab to be opened next to the previous tab, as well as to avoid starting
unnecessary new processes when creating the new browser window.

See Also: → 1756564
Depends on: 1719892
Status: NEW → ASSIGNED

This clarifies some of the members and arguments which were used in
DocumentLoadListener to make them more clear, adding documentation.

In addition to the simplifications of logic and improved naming, this
patch also moves the responsibility of managing StreamFilterRequest out
of DisconnectListeners so that stream listeners behave more
consistently, as the existing flag doesn't map well to whether or not
they should be cleared.

This was kept seperate from part 1 as it is largely a clarity
improvement, and may make it harder to see the important changes in that
part.

Depends on D143676

Pushed by nlayzell@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0a6670275796
Part 1: Redirect internally-handled attachment loads into new tabs, r=Gijs,smaug,necko-reviewers,dragana
https://hg.mozilla.org/integration/autoland/rev/b98d76ac48ed
Part 2: Update tests for new download behaviour, r=Gijs
https://hg.mozilla.org/integration/autoland/rev/d3c53d2d79fb
Part 3: Clarify "process switch" parameters in DocumentLoadListener, r=smaug

https://hg.mozilla.org/mozilla-central/rev/0a6670275796
https://hg.mozilla.org/mozilla-central/rev/b98d76ac48ed
https://hg.mozilla.org/mozilla-central/rev/d3c53d2d79fb

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
status-firefox101: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 101 Branch
Regressions: 1766682
Blocks: 1762868

Does this patch address the issue about saving as "document.pdf"? (I am still seeing the broken behaviour in the newest Nightly)

Basically, this "feature" in 98 completely broke downloading PDF invoices. In 97 and previous, or in other browsers, you click a link to download a PDF, the file saves as whatever file name the company's web developers chose (e.g. Company-AccountNumber-042022.pdf), and then you can just take the downloaded file in Finder/Explorer and plonk it wherever you want. Now, the user has to manually name every such document they download... or just use another browser.

This is not just "oh we'll help the user out by opening the PDF and if they want to save it, they can click the save button" - now the user has to manually name the file too, with no guidance as to what the file was intended to be named.

Success on the first issue in Nightly 20220430091922 -- page not replaced. Test URL:

https://tsdr.uspto.gov/#caseNumber=2974321&caseSearchType=US_APPLICATION&caseType=SERIAL_NO&searchType=documentSearch

Check the box for a document, then use the Download button above the list to generate a request. It now opens in a new tab.

(In reply to Vivien M. (he/him) from comment #46)

Does this patch address the issue about saving as "document.pdf"? (I am still seeing the broken behaviour in the newest Nightly)

In my test, the PDF originally is served with

Content-Disposition: attachment; filename=78344043.pdf

This is applied when I save the PDF from the viewer, so it seems to work in that scenario.

In 97 and previous, or in other browsers, you click a link to download a PDF, the file saves as whatever file name the company's web developers chose (e.g. Company-AccountNumber-042022.pdf), and then you can just take the downloaded file in Finder/Explorer and plonk it wherever you want.

Can you test in the latest Nightly? https://www.mozilla.org/firefox/channel/desktop/ (scroll past Beta and Developer, the patch is only in Nightly)

(In reply to jscher2000 from comment #47)

Success on the first issue in Nightly 20220430091922 -- page not replaced. Test URL:

https://tsdr.uspto.gov/#caseNumber=2974321&caseSearchType=US_APPLICATION&caseType=SERIAL_NO&searchType=documentSearch

Check the box for a document, then use the Download button above the list to generate a request. It now opens in a new tab.

(In reply to Vivien M. (he/him) from comment #46)

Does this patch address the issue about saving as "document.pdf"? (I am still seeing the broken behaviour in the newest Nightly)

In my test, the PDF originally is served with

Content-Disposition: attachment; filename=78344043.pdf

This is applied when I save the PDF from the viewer, so it seems to work in that scenario.

In 97 and previous, or in other browsers, you click a link to download a PDF, the file saves as whatever file name the company's web developers chose (e.g. Company-AccountNumber-042022.pdf), and then you can just take the downloaded file in Finder/Explorer and plonk it wherever you want.

Can you test in the latest Nightly? https://www.mozilla.org/firefox/channel/desktop/ (scroll past Beta and Developer, the patch is only in Nightly)

I was testing in the latest Nightly 20220430091922 . The USPTO.gov web site works fine for me. I note that the new tab displays a https://tsdrsec.uspto.gov/ts/... URL. So that web site behaves correctly.

Meanwhile, what got me interested in this was frustration with 99.0.1 trying to download a PDF invoice from Canadian wireless carrier Fido's web site. After finding this bug and seeing there was a patch, I tested it in Nightly 20220430091922 and got the same behaviour as in 99.0.1 - a new tab with a URL saying "blob:https://www.fido.ca/fbb69090-5fc4-4cc9-9860-[blah]" and when you hit save, it offers document.pdf. Their web site works perfectly in latest release version of Chrome and worked fine in Firefox until... two billing cycles ago, which, having now read this bug, I believe would line up with 98's release date. So, it seems to me that whatever the fix in 20220430091922 is... doesn't extend to the full scope of the problem when it comes to the file name issue.

I'm just an end-user so I am not sure how to figure out what Content-Disposition they are sending. Happy to provide more information if you tell me where to look.

(For the record, while the file name issue is far more problematic, I think this behaviour of forcing opening up a tab with the PDF is not good. In the old behaviour and/or Chrome's, you got a PDF directly downloaded and it was up to you whether to open it now or just go to your OS' downloads folder and file it or whatever. And if you wanted to download five months' worth of statements, you could just download all five months' at once, then open them up from your downloads folder once you have all five.
This new behaviour appears to assume the user would prefer that any PDF that would have otherwise landed in their downloads folder silently instead be opened up immediately in a new tab.
I note, too, that some organizations have web sites where there was a separate link for viewing a PDF (or viewing the information that would be in the PDF directly in a web page) vs downloading the PDF, and effectively, this behaviour is turning the download link into a view link. And frankly, this change was disorienting - for a year or two, you click a download link and you get a downloaded statement in your OS' downloads folder and overnight, you started getting a new tab with a blob: URL, a save button that defaults to document.pdf, and... huh? I admit that I don't understand what problem this change was intended to solve...)

(In reply to Vivien M. (he/him) from comment #48)

Meanwhile, what got me interested in this was frustration with 99.0.1 trying to download a PDF invoice from Canadian wireless carrier Fido's web site. After finding this bug and seeing there was a patch, I tested it in Nightly 20220430091922 and got the same behaviour as in 99.0.1 - a new tab with a URL saying "blob:https://www.fido.ca/fbb69090-5fc4-4cc9-9860-[blah]" and when you hit save, it offers document.pdf. Their web site works perfectly in latest release version of Chrome and worked fine in Firefox until... two billing cycles ago, which, having now read this bug, I believe would line up with 98's release date. So, it seems to me that whatever the fix in 20220430091922 is... doesn't extend to the full scope of the problem when it comes to the file name issue.

I'm just an end-user so I am not sure how to figure out what Content-Disposition they are sending. Happy to provide more information if you tell me where to look.

The blob URL is a document created in a web page by a script, and not downloaded directly from a web server. Firefox has fewer clues as to the intended name, although that might be from the download attribute on a link, if the PDF is opened using a link.

If it's a link, does right-click > Save Link As work? Not sure that works with scripted links.

(For the record, while the file name issue is far more problematic, I think this behaviour of forcing opening up a tab with the PDF is not good. In the old behaviour and/or Chrome's, you got a PDF directly downloaded and it was up to you whether to open it now or just go to your OS' downloads folder and file it or whatever. And if you wanted to download five months' worth of statements, you could just download all five months' at once, then open them up from your downloads folder once you have all five.
This new behaviour appears to assume the user would prefer that any PDF that would have otherwise landed in their downloads folder silently instead be opened up immediately in a new tab.
I note, too, that some organizations have web sites where there was a separate link for viewing a PDF (or viewing the information that would be in the PDF directly in a web page) vs downloading the PDF, and effectively, this behaviour is turning the download link into a view link. And frankly, this change was disorienting - for a year or two, you click a download link and you get a downloaded statement in your OS' downloads folder and overnight, you started getting a new tab with a blob: URL, a save button that defaults to document.pdf, and... huh? I admit that I don't understand what problem this change was intended to solve...)

Yes, previously users had to employ workarounds to view PDFs in a tab if they were served with Content-Disposition: attachment (i.e., install an extension to override it to inline, like No PDF Download). In Firefox 98+, attachment disposition is ignored if your PDF handling on the Settings page, Applications list, is set to "Open in Firefox".

If you generally prefer to view PDFs from disk rather than from the web content cache, you can change that setting to "Always ask" or "Use [relevant application]" or "Save file" instead.

I agree it is challenging for websites that prefer to offer different links, but I don't think that was a consideration in making the change.

I think a different bug should be filed for that issue.

(In reply to jscher2000 from comment #49)

(In reply to Vivien M. (he/him) from comment #48)

I'm just an end-user so I am not sure how to figure out what Content-Disposition they are sending. Happy to provide more information if you tell me where to look.

The blob URL is a document created in a web page by a script, and not downloaded directly from a web server. Firefox has fewer clues as to the intended name, although that might be from the download attribute on a link, if the PDF is opened using a link.

If it's a link, does right-click > Save Link As work? Not sure that works with scripted links.

Not a link - they give you a screen where you can check off a bunch of months and, at least if you check off only one month, when you click the "download PDF" button it either i) downloads a properly-named PDF containing that month's bill (the behaviour in Chrome or pre-98 Firefox) or ii) opens this blob: thing that saves as document.pdf (in 99 or the current Nightly).

I have a feeling that I have seen the same blob: issue with another company's system but I can't readily remember which one it is...

Yes, previously users had to employ workarounds to view PDFs in a tab if they were served with Content-Disposition: attachment (i.e., install an extension to override it to inline, like No PDF Download). In Firefox 98+, attachment disposition is ignored if your PDF handling on the Settings page, Applications list, is set to "Open in Firefox".

If you generally prefer to view PDFs from disk rather than from the web content cache, you can change that setting to "Always ask" or "Use [relevant application]" or "Save file" instead.

I agree it is challenging for websites that prefer to offer different links, but I don't think that was a consideration in making the change.

I think a different bug should be filed for that issue.

So, just to make sure I understand if I am going to open another bug - in pre-98 Firefox, Content-Disposition: attachment PDFs were downloaded straight to your OS download folder, while other PDFs followed your PDF handling setting? So... if you had a "normal" PDF link, it followed the PDF handling setting (which defaults to "Open in Firefox"), while if the web site developer added Content-Disposition: attachment, it honoured the web site developer's intended behaviour and straight downloaded it.

In 98+, both things are lumped together, so the wishes of developers who put Content-Disposition: attachment are ignored, unless you change the setting for all PDFs, in which case, to improve the behaviour of Content-Disposition: attachment scenarios... you've now changed the experience for non-Content-Disposition: attachment PDFs to something else like "Always ask", "Save files", or "Use Windows default application"... all of which produce a worse experience for a PDF you just want to read and not permanently save to your file system?

Before I open another bug, I guess it's time to do another search first - I can't be the only person who thinks this is a huge step backwards.

(In reply to Vivien M. (he/him) from comment #50)

So, just to make sure I understand if I am going to open another bug - in pre-98 Firefox, Content-Disposition: attachment PDFs were downloaded straight to your OS download folder, while other PDFs followed your PDF handling setting?

Before Firefox 98, the default was to show the Download dialog (Open/Save/Cancel) for files with Content-Disposition: attachment, regardless of the instructions on the list under Settings > Applications. You could not set Firefox to automatically save files with Content-Disposition: attachment.

Right now, there is a preference for whether the built-in PDF viewer takes files served with Content-Type: application/octet-stream a generic binary content-type (in about:config: pdfjs.handleOctetStream). As a starting point, it could be useful to have a similar preference for whether the built-in PDF viewer takes files served with Content-Disposition: attachment, understanding that users would need to go into about:config to toggle this if they don't like the default.

Frankly, I am not sure I should open another bug - certainly the first 10-15 comments up at the top address this very issue, and other bugs that were opened relating to this were marked as duplicate of this bug. So while this bug appears to have drifted into one or two narrower issues... is it appropriate to open a new bug?

(In reply to jscher2000 from comment #51)

(In reply to Vivien M. (he/him) from comment #50)

So, just to make sure I understand if I am going to open another bug - in pre-98 Firefox, Content-Disposition: attachment PDFs were downloaded straight to your OS download folder, while other PDFs followed your PDF handling setting?

Before Firefox 98, the default was to show the Download dialog (Open/Save/Cancel) for files with Content-Disposition: attachment, regardless of the instructions on the list under Settings > Applications. You could not set Firefox to automatically save files with Content-Disposition: attachment.

And many, many people went and designed web sites on the expectation of that behaviour. This is particularly true for web sites where the PDF is somewhat of a 'secondary' form of communication. For example, take an online banking web site - you would likely be able to view the transactions in your April 12 statement in a normal web page, then they give you a PDF link/script/something with Content-Disposition: attachment if you want to save a PDF of the April 12 statement. I would argue the only reason you click on the PDF link is because you want something to download/print - if you just wanted to review your transactions, you don't need the PDF. I'm sure I've ever seen web sites where there is a little disk icon for saving.

As I've said above, I'm an end-user. I download invoices and statements from various people's web sites (that I did not design!) in PDF form, go into Finder/Explorer and move the files to the proper location on my file system. Prior to 98, this worked correctly; post-98, I either have to jump through extra hoops (including losing the filenames, though that seems very partially fixed in the newest Nightly but not completely), use a different browser, or change the setting in Setting -> Applications and lose Firefox's built-in PDF viewing for non-Content-Disposition: attachment "normal" PDFs?

Am I the only person who downloads PDFs for my records of financial-type things that, frankly, I may not want to look at immediately? And who might want to download six months' worth in one shot without having to open a new tab, hit save, possibly change the file name, then close the tab, then click to download the next month, etc? This all worked perfectly up until two months ago, and now it's broken.

I've looked at bug 453455 and... it seems to me that this was never considered. Somehow, it seems that "it is annoying that I keep having these Content-Disposition: attachment PDFs being downloaded when I don't want them to be and there's no way to set "Open in Firefox" in the download dialog permanently" became "Content-Disposition: attachment should be ignored and any PDF designated that way should be treated according to the one single PDF setting."

Yet it seems to me that end users might want the PDFs the web site developers marked with Content-Disposition: attachment to be downloaded and the ones that web site developers didn't designate that way to be dealt with differently. Maybe some web site developers abuse Content-Disposition: attachment, but it seems like there is a distinction there that is useful, relevant, and followed by other browsers.

Right now, there is a preference for whether the built-in PDF viewer takes files served with Content-Type: application/octet-stream a generic binary content-type (in about:config: pdfjs.handleOctetStream). As a starting point, it could be useful to have a similar preference for whether the built-in PDF viewer takes files served with Content-Disposition: attachment, understanding that users would need to go into about:config to toggle this if they don't like the default.

I would agree with that... at the very least, this should be an about:config setting. Or maybe there should be two PDF types in Settings -> Applications.

(In reply to Vivien M. (he/him) from comment #50)

Before I open another bug, I guess it's time to do another search first - I can't be the only person who thinks this is a huge step backwards.

No, you're not the only one. I totally agree with you. It is a huge step backward.

I also download bank statements and invoices, so I felt the pain as an end-user. But I quickly change my Firefox PDF settings to "Always ask" and forgot about the problem. Then I realized most of our users switched to Chrome recently. I also make web apps, so I feel the pain of a developer. We had to add a condition in the app - if (itIsFirefox > 97) { do the workaround } to fix this unexpected (and annoying) behavior.

See Also: → 1767321

The issue where the default filename for the "save as" option in pdf.js which was specified by the website is being lost and replaced with "document.pdf" is a bug. I've filed bug 1767321 which should have a fix for that issue as well.

Flags: qe-verify+

Whymarrh, could you confirm that this fix addresses the original issue for you with Firefox 101, which is currently available through beta? ( https://beta.mozilla.org/ )

Flags: needinfo?(whymarrh.whitby)

Hi Gijs,

FYI, tested using firefox beta 101.0b2 (64-bit) in Ubuntu 20.04 installed from official ppa:

  • PDF is now opened in a new Tab (using WhatsApp web + my own app)
  • The default filename is lost and replaced with document.pdf as mentioned above

(In reply to :Gijs (he/him) from comment #55)

Whymarrh, could you confirm that this fix addresses the original issue for you with Firefox 101, which is currently available through beta? ( https://beta.mozilla.org/ )

Tested in Version 102.0a1 (Build ID 20220505113034) and the behaviour is now different and possibly better, but in my opinion, still not correct. The download attribute isn't respected, which doesn't make sense to me as a web author or as an end-user when the link/button text says "Download."

I do see that the filename supplied via the download attr is correctly offered as the default in the "Save As" window.

(In reply to Whymarrh Whitby from comment #1)

This is also reproducible using PDFKit's example: https://pdfkit.org/demo/browser.html

The PDFKit example also opens in a new tab, despite the download attribute being present.

Flags: needinfo?(whymarrh.whitby)

(In reply to Whymarrh Whitby from comment #57)

(In reply to :Gijs (he/him) from comment #55)

Whymarrh, could you confirm that this fix addresses the original issue for you with Firefox 101, which is currently available through beta? ( https://beta.mozilla.org/ )

Tested in Version 102.0a1 (Build ID 20220505113034) and the behaviour is now different and possibly better, but in my opinion, still not correct. The download attribute isn't respected, which doesn't make sense to me as a web author or as an end-user when the link/button text says "Download."

Thank you for checking. As previously discussed (e.g. comment 15), I think we differ in our sense of expectation here. Content-disposition: attachment and (same-origin) <a download> are supposed to be treated the same, and our experience (through many duplicates of the bug mentioned there, but also e.g. bug 1655974) is that users do not understand why their configuration (for PDFs or other files) would apply to some downloads (ones without Content-Disposition: attachment), but not other downloads - it makes the behaviour unpredictable, and moves control from the user to the website. As a result, we're specifically trying not to distinguish those cases, both for PDFs and for other filetypes. While I agree that that has the potential to be confusing given website labelling, I would argue that that confusion is unavoidable, as the alternative (treating some files differently from other files) is also confusing, and at this point in time we've erred on the side of consistency wrt user expectations/settings, and prioritizing user preferences over website preferences.

The point of the work in this bug was specifically to address the issue around website contents being replaced unexpectedly, and it sounds like that was successful.

(In reply to rchavik from comment #56)

  • The default filename is lost and replaced with document.pdf as mentioned above

Thanks, the filename fix landed after the beta branch date and is currently only available on nightly. We could uplift to beta but there's a comment in bug 1767321 suggesting that that was only partially resolved (but the broken testcase involves having an account with a Canadian ISP, so isn't super easy for us to reproduce), so it would be useful if you could check if it works on nightly with your testcases, esp. if those are publicly accessible, and comment there if you are also still seeing issues.

(In reply to :Gijs (he/him) from comment #58)

While I agree that that has the potential to be confusing given website labelling, I would argue that that confusion is unavoidable, as the alternative (treating some files differently from other files) is also confusing, and at this point in time we've erred on the side of consistency wrt user expectations/settings, and prioritizing user preferences over website preferences.

An issue I didn't see much discussed here (maybe because it's not really part of the "bug" but more of a design choice) is that the user preferences for PDF have changed to be set to "open" by default while before it was either asking the user or just saving (not sure which one).
While the option to change this behavior by the user exists, changing the default value will inevitably cause mayhem, even more so for users that didn't even knew this was a setting in the first place.

In addition to the issue that are getting fixed here, maybe asking the user for his choice instead of imposing a new value on him on new installations would be better.

(In reply to :Gijs (he/him) from comment #58)

(In reply to Whymarrh Whitby from comment #57)

Tested in Version 102.0a1 (Build ID 20220505113034) and the behaviour is now different and possibly better, but in my opinion, still not correct. The download attribute isn't respected, which doesn't make sense to me as a web author or as an end-user when the link/button text says "Download."

Thank you for checking. As previously discussed … I think we differ in our sense of expectation here.

The point of the work in this bug was specifically to address the issue around website contents being replaced unexpectedly, and it sounds like that was successful.

Understood, and thank you for laying out your case. While we disagree, this new behaviour is definitely better and I am happy this no longer breaks applications.

Perhaps this screenshot will help make the point we are trying to make. The web site developers created two links: view and download. The expectation, and I presume it works accordingly in every other browser though I have not tried, is that if you click "View", you get your PDF statement opening in a new tab in your browser, and if you click "Download" you get a PDF file in your default download location that you can do whatever with.

Firefox 98+ has decided, in the name of "consistency", that both of those links ought to behave the same. Our view is that they are different, that the web site developers intended them to behave differently, that the web site developers created UIs that lead end-users to expect them to behave differently, and that Firefox should honour the web site developers' intentions and end-users' resulting expectations rather than treat two things that were intended to be different as being the same.

I popped up a basic test page: https://www.jeffersonscher.com/res/disposition.html

This does not address the client-side blob file naming issue under discussion in bug 1767321.

(In reply to cleyfaye from comment #59)

An issue I didn't see much discussed here (maybe because it's not really part of the "bug" but more of a design choice)

Right, this was a separate change.

is that the user preferences for PDF have changed to be set to "open" by default while before it was either asking the user or just saving (not sure which one).

No, the previous default as shown in the preferences/settings was also "open in Firefox", specifically for PDFs (though that didn't work for Content-Disposition: attachment PDFs, which is what this bug is related to - so you might still have seen the dialog in the past, even though that wasn't what was configured in the Firefox settings). It was "always ask" for lots of other filetypes though.

While the option to change this behavior by the user exists, changing the default value will inevitably cause mayhem, even more so for users that didn't even knew this was a setting in the first place.

This seems unlikely given that "always ask" wasn't the default for PDFs, though there was also a risk of changing it accidentally, cf. bug 1660277 - so no real guarantee that the setting being "always ask" was intentional in the first place.

In addition to the issue that are getting fixed here, maybe asking the user for his choice instead of imposing a new value on him on new installations would be better.

"always ask" is a boolean state - Firefox also saves the default action in the dialog (but this isn't visible in the settings). As part of the 98 release, we overwrote the boolean state with false (ie don't ask), because we anticipated that if we didn't do so, users would be confused why some files would then download without prompting, and others would continue prompting (because they were set to always ask, which as noted above could happen without a firm user action to that effect). This would also have affected PDF settings, and what that setting got switched to would depend on what the user's preferred action had previously been in the dialog. In your case, sounds like it was "open in Firefox".

It's become clear (also elsewhere) that this has surprised/upset some folks (even if our intentions were precisely to avoid surprise/confusion!), and we'll take that into account going forward if we have to make similar changes in the future. I do want to point out that "ask me/the user before changing anything" isn't a feasible strategy to apply to every change in the browser - many people would be asked about things they don't use, things they don't understand, and things they don't care about - and so it's always a trade-off between how to avoid unnecessarily interrupting people, which changes are notable/important to people's workflows, etc.

Given the breadth of the web and the variety in usage patterns in our userbase, this is almost impossible to get 100% right 100% of the time - so we'll keep learning and trying to do better.

(In reply to Vivien M. (he/him) from comment #61)

Created attachment 9275423 [details]
Example of the kind of interface this is breaking.

Perhaps this screenshot will help make the point we are trying to make.

We understand the point you are trying to make fine, and at this point it probably isn't helpful to repeat it.

I presume it works accordingly in every other browser though I have not tried,

I just checked, both Safari and Chrome treat the "attachment" example in https://www.jeffersonscher.com/res/disposition.html the same as the "inline" example, showing the PDF in the browser, rather than downloading it (ie they work just like Firefox in that case). Only the <a download> example gets saved. So, depending on how the website you screenshotted implemented things, it may or may not do the same thing as Firefox and not download the PDF.

Firefox 98+ has decided, in the name of "consistency", that both of those links ought to behave the same. Our view is that they are different

I don't disagree. But the problem is that not every site that hands the user a PDF offers both options, or labels them with clear expectations of whether a download or "view" tab will result. The fact is, the site doesn't have much control over how the browser deals with either situation. For the many users who disable Firefox's (and/or Chrome's/Safari's/Edge's...) inline PDF viewer, both links will download (so the "view" link doesn't "work", as far as the user is concerned - there's relatively new standards work to allow the website to tell if inline PDF viewing is supported to avoid this).

The browser can't tell with 100% certainty what the user's understanding and/or agreement with the site's intent is, and is constrained in how it responds to either. If we made Firefox behave "unsurprisingly" in your example, it would behave "surprisingly" in other examples. For now, we have chosen to opt for the current behaviour.

(In reply to jscher2000 from comment #62)

I popped up a basic test page: https://www.jeffersonscher.com/res/disposition.html

This does not address the client-side blob file naming issue under discussion in bug 1767321.

Thanks, jscher. Just to confirm, I get the correct filename on nightly with your testcase - are you seeing the same thing?

Nika, it seems based on very very lightweight testing (with jscher's testcase) that Chrome/Safari differentiates between Content-Disposition: attachment and <a download>. Am I right in thinking this, and if so, is there any basis for this in the spec, and/or should we consider doing the same?

Flags: needinfo?(nika)
Flags: needinfo?(jscher2000)
Blocks: 1742648

(In reply to :Gijs (he/him) from comment #58)

(In reply to Vivien M. (he/him) from comment #61)

I presume it works accordingly in every other browser though I have not tried,

I just checked, both Safari and Chrome treat the "attachment" example in https://www.jeffersonscher.com/res/disposition.html the same as the "inline" example, showing the PDF in the browser, rather than downloading it (ie they work just like Firefox in that case). Only the <a download> example gets saved. So, depending on how the website you screenshotted implemented things, it may or may not do the same thing as Firefox and not download the PDF.

Okay, so I tested it in Safari just now. "View" did... nothing, because it got caught by the popup blocker. (LOL! I figured I would note that because it's mildly amusing that, without allowing it in the popup blocker, the view link is broken...) Once I allowed it in the popup blocker, view opens a new tab with a blob: URL and the PDF is displayed in it. "Download" asks "Do you want to allow downloads on “secure.eqbank.ca”?" When I said "Yes", the PDF went straight into my downloads folder.

Happy to test Chrome if you would like.

But Safari, at least, delivered exactly the experience that I presume the web developers intended. The same experience that pre-98 Firefox delivered.

Firefox 98+ has decided, in the name of "consistency", that both of those links ought to behave the same. Our view is that they are different

I don't disagree. But the problem is that not every site that hands the user a PDF offers both options, or labels them with clear expectations of whether a download or "view" tab will result. The fact is, the site doesn't have much control over how the browser deals with either situation. For the many users who disable Firefox's (and/or Chrome's/Safari's/Edge's...) inline PDF viewer, both links will download (so the "view" link doesn't "work", as far as the user is concerned - there's relatively new standards work to allow the website to tell if inline PDF viewing is supported to avoid this).

The browser can't tell with 100% certainty what the user's understanding and/or agreement with the site's intent is, and is constrained in how it responds to either. If we made Firefox behave "unsurprisingly" in your example, it would behave "surprisingly" in other examples. For now, we have chosen to opt for the current behaviour.

These developers are doing something to trigger that download experience. Whether it's <a download>, Content-Disposition: attachment, or something else (sorry, I don't have the expertise to tell you for any given web site...), they are doing something that is intended to signal to the browser "I would like the download behaviour please." One would like to hope that their UI is communicating that to the end-user as well (as the example in my screenshot does), but if it isn't, I don't see how that is the browser's problem. The browser was asked to deliver the download behaviour, the browser should deliver the download behaviour unless there's something glaringly abusive about doing so, and if the end-user is unhappy about the download behaviour and/or the UI the web site gave them promised something other than the download behaviour, then it seems to me like the response is "uhhh, take it up with the web developers - they are the ones asking for the download behaviour but leading you to expect something else."

There may be all kinds of other scenarios where various behaviour, including the old behaviour, would fall into the "surprisingly" category, sure. But how is disregarding an explicit request from the web site to provide the download behaviour ever going to fall under the "unsurprisingly" category unless the web site promised the end-user the non-download behaviour but then requested the download behaviour from the browser?

Sure, this patch (opening in new tabs instead of same tab), the patch to address at least some scenarios when it comes to file names, etc. will help mitigate the problems this change has caused, but... ignoring the fact that these companies probably don't care at all about Firefox (sadly...), is there a workaround? If I could somehow find the lead web developer at the bank for which I posted the screenshot, is there something he/she could change to make Firefox 98+ deliver the behaviour he/she and I both want?

(In reply to :Gijs (he/him) from comment #63)

(In reply to jscher2000 from comment #62)

I popped up a basic test page: https://www.jeffersonscher.com/res/disposition.html

This does not address the client-side blob file naming issue under discussion in bug 1767321.

Thanks, jscher. Just to confirm, I get the correct filename on nightly with your testcase - are you seeing the same thing?

Yes, in the scenario of

<a href="name1.pdf" download="name2.pdf">

Nightly correctly uses name2.pdf in place of the actual file name in the URL when the PDF is sent from the server and opened in the built-in viewer and then saved using the viewer's download button.

I did not try to figure out how to create a PDF as a blob, so the test page doesn't address that particular case.

Flags: needinfo?(jscher2000)

For the sake of testing, I believe you could add this to this page to get the blob behavior:

const blob = await (await fetch("https://www.jeffersonscher.com/res/bugzilla-home.pdf")).blob();
const url = URL.createObjectURL(blob);
const a = document.createElement("a"); // alternatively just get an existing <a> element
a.href = url;
a.innerText = "download blob";
document.querySelector("html").appendChild(a);

(In reply to cleyfaye from comment #66)

For the sake of testing, I believe you could add this to this page to get the blob behavior:

I didn't know that was possible. Very interesting!

So when I use that approach to populate the blob as the href of the fourth link on https://www.jeffersonscher.com/res/disposition.html, the file name from download="bugzblob.pdf" is used for saving from the viewer when it opens in a new tab (in Nightly 20220508065845).

In short, all good for me.

(In reply to :Gijs (he/him) from comment #63)

Nika, it seems based on very very lightweight testing (with jscher's testcase) that Chrome/Safari differentiates between Content-Disposition: attachment and <a download>. Am I right in thinking this, and if so, is there any basis for this in the spec, and/or should we consider doing the same?

The download attribute behaviour appears to be documented as happening through https://html.spec.whatwg.org/multipage/links.html#downloading-resources, where the reference to this roughly says (https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-a-element):

The activation behavior of an a element element given an event event is:
[...]
4. If element has a download attribute, or if the user has expressed a preference to download the hyperlink, then download the hyperlink created by element given hyperlinkSuffix.

The download the hyperlink actions basically say to start a fetch, and then:

  1. Handle the result of fetching request as a download

The case of a Content-Disposition header is handled seperately when processing a navigation response (https://html.spec.whatwg.org/multipage/browsing-the-web.html#process-a-navigate-response), where it says roughly:

  1. If response has a Content-Disposition header specifying the attachment disposition type, then:
    1. If allowedToDownload is true, then handle response as a download.

Both of these end up in the common code to "handle a resource obtained from a fetch as a download" (https://html.spec.whatwg.org/multipage/links.html#as-a-download), meaning that they're not meaningfully treated differently by the web standard, though it doesn't surprise me that browsers implement them differently. In general with things like this, there's a lot of latitude as to what user agents choose to do at this point.

I have no strong opinions about whether or not we try to do something different for the two download codepaths. Right now we implement the download attribute by effectively pretending that the response has an attachment content disposition, meaning we largely share the same codepath for both the download attribute and the response header, but we could probably look into doing something different if we wanted to by tracking the source of the content-disposition hint, or changing how we override it in some places. It'd be some work to detangle them though.

Flags: needinfo?(nika)
Regressions: 1767321
No longer regressions: 1767321

I managed to reproduce this on Firefox 100.0(20220428192727) on Win10 64-bits. I can confirm the fix on Firefox 101.0b7(20220515185854), Nightly 102.0a1(20220517092745) on Win10 64-bits, Ubuntu 20.04 and macOS 11.

Status: RESOLVED → VERIFIED
status-firefox101: fixed → verified
Flags: qe-verify+

It's perhaps worth noting here, given it was of interest to various people here, that we've reverted back to treating PDFs with Content-Disposition: attachment and/or <a download> links as "special", and will download them, even if Firefox is set to open PDFs itself. This happened in bug 1772569, and will ship with Firefox 103. If you preferred the behaviour we had for these few releases (probably few people in this bug, but never mind...) you can switch back by toggling browser.download.open_pdf_attachments_inline to true in about:config.

Thanks for the heads up. We had some less than satisfactory workaround implemented for this specific case I'll be happy to remove (at least for the time being).

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: