Die Funktionalität dieser Website ist durch Wartungsarbeiten eingeschränkt, die Ihr Erlebnis verbessern sollen. Wenn ein Artikel Ihr Problem nicht löst und Sie eine Frage stellen möchten, können Sie unsere Gemeinschaft über @FirefoxSupport auf Twitter, /r/firefox oder Reddit fragen.

Hilfe durchsuchen

Vorsicht vor Support-Betrug: Wir fordern Sie niemals auf, eine Telefonnummer anzurufen, eine SMS an eine Telefonnummer zu senden oder persönliche Daten preiszugeben. Bitte melden Sie verdächtige Aktivitäten über die Funktion „Missbrauch melden“.

Weitere Informationen

Problem with HTMLCanvasElement.toBlob(), "image/webp", & anchor (<a>) using download attribute

  • 1 Antwort
  • 0 haben dieses Problem
  • Letzte Antwort von E.C. Marm

more options

I have a local HTML/Javascript document I use for compressing local image files. It relies on HTMLCanvasElement.toBlob() to achieve the compression in the usual way; a pertinent excerpt:

                   const output = document.getElementById("outputDiv");
                   const blobURL = URL.createObjectURL(file);
                   const img = new Image();
                   img.src = blobURL;
                   // ...
                   img.onload = function () {
                       URL.revokeObjectURL(this.src);
                       const canvas = document.createElement("canvas");
                       canvas.width = img.width;
                       canvas.height = img.height;
                       const ctx = canvas.getContext("2d");
                       ctx.drawImage(img, 0, 0, img.width, img.height);
                       canvas.toBlob(
                           (blob) => {
                               const anchor = document.createElement("a");
                               anchor.download = getNewFileName(file.name); /* uses extension .webm for .webm, .jpg for everything else */
                               anchor.href = URL.createObjectURL(blob);
                               anchor.textContent = "DOWNLOAD";
                               output.append(anchor);
                           },
                           mime,  /* set earlier based on file extension: .webm -> "image/webm", everything else -> "image/jpeg"
                           quality / 100    /* (user-specified) */
                       );
                   };

Here's the quirky thing, though: when I'm compressing, say, a .jpeg file (or a .png), clicking on the download link opens a save-file dialog, but when using a .webm file, it opens the compressed image in a new tab! True, I can always then save the image from there (the resulting file is in Firefox's temp folder), but I don't understand the difference in behavior -- and indeed, in at least one other browser I tried (the latest Vivaldi) the download happens as expected regardless of input file type. In all cases the anchor hrefs look like, e.g., "blob:null/724ab85e-53ba-4890-9868-7f1ba27d4278".

Any idea why this is happening? I highly doubt it's the intended behavior.

Browser: Firefox 132.0.2 for Windows. Environment: Windows 10 Home 22H2 version 10.0.19045.

I have a local HTML/Javascript document I use for compressing local image files. It relies on HTMLCanvasElement.toBlob() to achieve the compression in the usual way; a pertinent excerpt: const output = document.getElementById("outputDiv"); const blobURL = URL.createObjectURL(file); const img = new Image(); img.src = blobURL; // ... img.onload = function () { URL.revokeObjectURL(this.src); const canvas = document.createElement("canvas"); canvas.width = img.width; canvas.height = img.height; const ctx = canvas.getContext("2d"); ctx.drawImage(img, 0, 0, img.width, img.height); canvas.toBlob( (blob) => { const anchor = document.createElement("a"); anchor.download = getNewFileName(file.name); /* uses extension .webm for .webm, .jpg for everything else */ anchor.href = URL.createObjectURL(blob); anchor.textContent = "DOWNLOAD"; output.append(anchor); }, mime, /* set earlier based on file extension: .webm -> "image/webm", everything else -> "image/jpeg" quality / 100 /* (user-specified) */ ); }; Here's the quirky thing, though: when I'm compressing, say, a .jpeg file (or a .png), clicking on the download link opens a save-file dialog, but when using a .webm file, it opens the compressed image in a new tab! True, I can always then save the image from there (the resulting file is in Firefox's temp folder), but I don't understand the difference in behavior -- and indeed, in at least one other browser I tried (the latest Vivaldi) the download happens as expected regardless of input file type. In all cases the anchor hrefs look like, e.g., "blob:null/724ab85e-53ba-4890-9868-7f1ba27d4278". Any idea why this is happening? I highly doubt it's the intended behavior. Browser: Firefox 132.0.2 for Windows. Environment: Windows 10 Home 22H2 version 10.0.19045.

Alle Antworten (1)

more options

In the immortal words of Miss Emily Litella, "Never mind!" I figured it out all by my lonesome, and the answer is this:

The problem is not where my .webp (pardon multiple typos of ".webm" above!) image comes from or anything involving the anchor tag, but rather in my default Firefox settings. Under General -> Files and Applications -> Applications, the Action for Content Type "WebP Image" is set to "Open in Firefox" -- which, in a new tab, is exactly what's happening! And why does the "JPEG Image" type act differently? Because its Action is set to "Save File", the same as the PNG & SVG types. Curiously, AV1/AVIF defaults to "Open in Firefox", like WebP. I seriously doubt there's any way to change a Content Type's default Open/Save action on a per-anchor rather than a per-type basis, though please let me know if I'm wrong.

So my question now is this: why the different default Actions for different image types (JPEG, PNG, WebP, & AV1)? I fail to see why they shouldn't be the same, whether Open or Save. Might WebP's default be simply a relic from the bygone days when Firefox didn't support that type very well?

Hilfreich?

Stellen Sie eine Frage

Sie müssen sich mit Ihrem Benutzerkonto anmelden, um auf Beiträge zu antworten. Bitte stellen Sie eine neue Frage, wenn Sie noch kein Benutzerkonto haben.