所有產品 社群討論區

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.

FF v132.0.2 (64-bit). We utilize Sharepoint/Microsoft 365, and since switching to Firefox, the zoom controls normally located in the lower righthand corner for Excel spreadsheets is just gone. This is with extensions disabled, even tried Private View. Chrome properly shows it.

Screenshots attached showing Firefox/Chrome. That basically eliminates our ability to use FireFox if that's the case since there's no other way to do it.

I'm logged in to my Firefox account, I visit (for example) ESPN.com on my PC. I adjust the size to fit my PC screen, then when I visit the same site on my laptop the website doesn't look right so I have to size down, but then when I visit on my PC I have to size up again etc etc etc.

I want to individualize the size of webpages, how do I do that?

I beleive in the recent versions of Firefox, shortcut keys have been added/changed such that holding the Option key while in the URL Search bar activates other functions (Switching search engines: Option + Up/Down Arrow) and completely disables my ability to move left or right through the URL by word.

Is there any way I can disable this shortcut key combination?

once in a while firefox forces me to double click everything. This does not apply to the top of the window: tabs, URL bar, bookmarks toolbar, extensions all work fine. But everything in the webpage requires a double click. This includes selecting text. A restart makes it go away.

The only extensions I had in use when this happened were uBlock origin, proton pass, and SponsorBlock. Switching into troubleshoot mode fixed it, but after switching back into normal mode it was still fixed, so I can't say that the extensions cause the issue.

I would have just commented on [this related thread](https://support.mozilla.org/en-US/questions/1038784), but it's archived. I never understood the point of archiving a thread. From now until the end of time when people find that thread when googling their issue, there's no way to give them new information. At least in a github issue it can still include a link to other threads that have mentioned it.

I am running firefox 132.0.2 (aarch64) on macos 15.0 (24A335).