Open Bug 1752739 Opened 3 years ago Updated 2 years ago

Separate "Open with Firefox/Nightly" option does not show for PDFs from blob urls/downloads if PDFs are set to always ask

Categories

(Firefox :: File Handling, defect, P5)

Firefox 96
Desktop
All
defect

Tracking

()

Tracking Status
firefox-esr91 --- wontfix
firefox96 --- wontfix
firefox97 --- wontfix
firefox98 --- wontfix
firefox99 --- wontfix
firefox100 --- wontfix

People

(Reporter: kernp25, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96.0

Steps to reproduce:

  1. Download a pdf from a blob url (https://www.aspsnippets.com/Articles/JavaScript-Save-BLOB-as-PDF-File.aspx)

Actual results:

Does not show "Open with Firefox/Nightly"

Flags: needinfo?(gijskruitbosch+bugs)

Here is the code from https://www.aspsnippets.com/Articles/JavaScript-Save-BLOB-as-PDF-File.aspx:

        function DownloadFile(fileName) {
            //Set the File URL.
            var url = "Files/" + fileName;

            //Create XMLHTTP Request.
            var req = new XMLHttpRequest();
            req.open("GET", url, true);
            req.responseType = "blob";
            req.onload = function () {
                //Convert the Byte Data to BLOB object.
                var blob = new Blob([req.response], { type: "application/octetstream" });

                //Check the Browser type and download the File.
                var isIE = false || !!document.documentMode;
                if (isIE) {
                    window.navigator.msSaveBlob(blob, fileName);
                } else {
                    var url = window.URL || window.webkitURL;
                    link = url.createObjectURL(blob);
                    var a = document.createElement("a");
                    a.setAttribute("download", fileName);
                    a.setAttribute("href", link);
                    document.body.appendChild(a);
                    a.click();
                    document.body.removeChild(a);
                }
            };
            req.send();
        };

Note: -It does not chanhe anything, if i change application/octetstream to application/pdf

(In reply to kernp25 from comment #1)

Note: -It does not chanhe anything, if i change application/octetstream to application/pdf

Should be: Note: It does not change anything, if i change application/octetstream to application/pdf

Is this

Regressed by: 1672384

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

Component: Untriaged → PDF Viewer

works for me with nightly (98) on Win10.

when opening the URL mentioned and click on "View Demo" it brings up this URL: https://www.aspsnippets.com/demos/3204/
Clicking on "Download PDF file" opens ths PDF in pdf.js.

Component: PDF Viewer → File Handling

Given comment #5, can you provide more precise STR? Perhaps it requires a certain pref to be set, or a particular handler configuration?

Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(kernp25)

Set release status flags based on info from the regressing bug 1672384

Has Regression Range: --- → yes
Attached video firefox_sVO32jYuiN.mp4

Because of bug 1053327, it will display now from: https://www.aspsnippets.com.

Flags: needinfo?(kernp25) → needinfo?(gijskruitbosch+bugs)
Attached image ask.png

Kernp25:

-I tried installing firefox nightly 98 on windows10 64bit.
-Then i changed the Firefox settings for pdf to "always ask."
-Then i went to https://www.aspsnippets.com/demos/3204/
-Downloaded the PDF, and i got the download prompt

At first try i was given only the edge option. but i clicked next to "open with" and in the dropdown i selected "Other" and then i chose Firefox Nightly. (this is ofnen mitt on your video, click on "Firefox standard" and select the last option to choose the program you would like to open it with)

after that firefox nightly was shown, and after restarting i always had Firefox nightly

can you try?

Flags: needinfo?(kernp25)

Hi Gigs

Per last comment, Im not sure if this is a bug, i have other programs to open PDFs installed and they did not show up as a default option on the download modal prompt. Maybe this is windows related and selects its own browser as the default on the first download and then you need to click on other and select the one you want.

I belive this is related to windows10 since it has its own setting called "choose default apps by file type"
In there by default the microsoft browser will appear.

Im i right?

Or firefox should force the default in the download prompt ?

I mean the "Open with Firefox" option added by bug 773942.

Flags: needinfo?(kernp25)

thanks,

I tried this with windows10 64 bit and the "Open with Firefox" first option is missing since nightly 86.0a1 dated 2021-01-07, it shows up in nightly 2021-01-06

i tried to run mozregression and it failed giving me a message: "unable to find enough data to bisect"

changeset: 83f3726c41f9c91a9bd8e146a3422e287c4a9354
pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dd21b22c480175ca00f0834dbd4d9c1684aa85d2&tochange=83f3726c41f9c91a9bd8e146a3422e287c4a9354
repo_name: mozilla-central

I will set the bug as new for now.

Status: UNCONFIRMED → NEW
Ever confirmed: true

The option isn't shown because we mistakenly assume that in this case the PDF download comes from an existing PDF viewer.

The "correct" way of checking that would be to look for the triggering principal on the channel, but in the context of the dialog, that principal is not available. Or, alternatively, have some way for the PDF viewer's download button to indicate that that is what is causing the "what do you want to do with this file" dialog to show up - but again, that's not easily possible today because of the many layers of abstraction inbetween.

Because those options aren't trivial to implement, people have tried using simpler, different checks, and we keep finding edgecases where they don't work properly. bug 1672384 was one such case (whose fix caused this bug), bug 1726902 is another. There were a few other ones that I don't have to hand right now.

With the download improvements pref turned on (current nightly or beta), the PDF "save as" button will prompt for a location instead of showing the "what do you want to do" dialog, so perhaps the whole thing will be moot once that lands and stays enabled everywhere. If we need to continue to support the case where we do show that dialog, we would need to do some of the rearchitecting alluded to earlier, in order to fix this.

It's not clear to me how common this case is. Off-hand it seems neither common nor particularly severe. I don't think the ASP snippets page is particularly high profile. Are there high profile websites (e.g. banks or w/e) that are doing this that are breaking things for you? And is there a particular reason, if you want the PDFs to show in Firefox, not just to configure Firefox as such (ie to always open PDFs in Firefox) and then for the PDFs where you do want to save them, to use the appropriate PDF.js toolbar item and/or shortcut? That would seem like a reasonable workaround, especially on nightly/beta where the download improvements pref and the work in bug 1719892 would mean you could just open the PDF directly from the internet.

Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(kernp25)
OS: Unspecified → All
Hardware: Unspecified → Desktop
Summary: "Open with Firefox/Nightly" does not show for pdfs from blob urls/downloads → Separate "Open with Firefox/Nightly" option does not show for PDFs from blob urls/downloads if PDFs are set to always ask
Severity: -- → S4

set severity to S4

(In reply to Pablo from comment #16)

set severity to S4

I'm going to clear this again because I'd like to understand the usecase / frequency that this is a problem for folks better, per my previous needinfo. Hopefully the reporter can offer some more details. I wouldn't want to dismiss the severity of the bug without understanding how this is impacting users, for which it feels like maybe I'm still missing something.

Severity: S4 → --
No longer blocks: 1744297
Priority: -- → P3
See Also: → 1751061

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

I'd like to understand the usecase / frequency that this is a problem for folks better. I wouldn't want to dismiss the severity of the bug without understanding how this is impacting users, for which it feels like maybe I'm still missing something.

As a data point... I, too, landed here because I was trying to do the same thing (I think) as the OP:

I'm trying to figure out how to offer users a "Best of Both Worlds" experience; a Download PDF button that:

  • Displays a URL in the lower corner when you hover over it (i.e., an <a href="..."> that's styled to look like a button)
  • Becomes disabled when you click it
    • The process could take more than a handful of seconds, and I don't want them to get impatient, and click it again and again
  • Contacts the server to generate a PDF w/ HTTP response headers:
    • Content-Disposition: attachment; filename="XYZ.pdf"
    • Content-Type: application/pdf, etc.
  • When the download completes, the link/button becomes un-disabled; and
  • Displays the standard prompt for whether they want to:
    • "Open with Firefox"
    • "Open in.... (Preview.app, etc.)", or
    • "Save File"

[N.B. GET is fine, but POST could eventually be useful, as well...]

The following [Vue-based template] gives me the hovering and the full "Open with Firefox" menu item, but not the disabled status or ability to POST:

<a class="btn btn-success"
  :href="`/form/${ form_id };download-pdf`"
  v-text="Download PDF"
/>

Whereas the following gives me all the hovering, disabled and POST behavior, but lacks the "Open with Firefox" menu item:

<a class="btn btn-success"
  :href="`/form/${ form_id };download-pdf`"
  :disabled="download_disabled"
  @click.prevent="downloadPDF"
  v-text="Download PDF"
/>
<script>
/* ... */
  methods: {
    downloadPDF: async function(evt) {
      this.downloading = true
      const res = await this.$http.get(evt.target.href, { responseType: 'arraybuffer' })

      const header   = res.headers.get('content-disposition')       || ""
      const encoded  = header.replace(/.*filename="(.*?)".*/, "$1") || ""
      const fileName = decodeURIComponent(encoded) || `${ this.form_id }.pdf`

      // Delegate the `createElement('a')` + `createObjectURL(blob)` + `click()`
      // work to:  https://github.com/eligrey/FileSaver.js
      saveAs( new Blob([res.data], { type: res.headers.get('content-type') || "application/pdf" }), fileName, false)

      this.downloading = false
    },
  },
}
</script>

(In reply to Dabe Murphy from comment #18)

I'm trying to figure out how to offer users a "Best of Both Worlds" experience; a Download PDF button that:

  • Displays a URL in the lower corner when you hover over it (i.e., an <a href="..."> that's styled to look like a button)
  • Becomes disabled when you click it
    • The process could take more than a handful of seconds, and I don't want them to get impatient, and click it again and again
  • Contacts the server to generate a PDF w/ HTTP response headers:
    • Content-Disposition: attachment; filename="XYZ.pdf"
    • Content-Type: application/pdf, etc.

The expected experience in most cases is that the pdf will open in the Firefox reader and then, if the user wants to save the file they can use the Download button on the pdf reader toolbar.
Or, you can enforce a download using an octet-stream mime.

  • When the download completes, the link/button becomes un-disabled; and

I don't think you can track the completion of the download from the website, or at least not easily, you should use some hack with Service Workers or LocalStorage, for which it sounds simpler to just re-enable the button on a timer.

This is no more a concern, because the pdf reader doesn't show the dialog anymore as explained in comment 15. There is some code and tests removal to do though, since the case cannot happen but it's all behind the downloads improvement pref. So I'm setting low priority as a code removal bug. Also see Bug 1751061.

Severity: -- → S4
Priority: P3 → P5

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Flags: needinfo?(kernp25)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: