搜索 | 用户支持

防范以用户支持为名的诈骗。我们绝对不会要求您拨打电话或发送短信,及提供任何个人信息。请使用“举报滥用”选项报告涉及违规的行为。

详细了解

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

  • 1 个回答
  • 0 人有此问题
  • 最后回复者为 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.

所有回复 (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?

有帮助吗?

我要提问

您需要登录才能回复。如果您还没账号,可以提出新问题