Open Bug 1827115 Opened 1 year ago Updated 6 months ago will not save a .url file


(WebExtensions :: General, defect, P2)

Firefox 112


(firefox-esr102 affected, firefox112 wontfix, firefox113 wontfix, firefox114 wontfix, firefox115 wontfix, firefox116 wontfix, firefox117 wontfix, firefox118 fix-optional)

Tracking Status
firefox-esr102 --- affected
firefox112 --- wontfix
firefox113 --- wontfix
firefox114 --- wontfix
firefox115 --- wontfix
firefox116 --- wontfix
firefox117 --- wontfix
firefox118 --- fix-optional


(Reporter: xdhmoore, Unassigned, NeedInfo)




(Keywords: regression, Whiteboard: [addons-jira])

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

Steps to reproduce:

On Windows 10:

  1. Install QuickCut addon from
  2. Go to
  3. Open the browser console Ctl+Shift+J
  4. Click the QuickCut icon in the extensions menu

Actual results:

The browser should download a file named Google.url which is a Windows shortcut file to

Expected results:

No file is downloaded and the browser console prints

Error: filename must not contain illegal characters

If you go to about:debug, click the extension, and put a breakpoint on the line:, (error) => console.log(error));

and then before it executes change downloadSettings.filename to Google.txt it saves the file successfully. Therefore, I believe it is the .url that is being blocked. Also, this addon worked correctly until a few weeks ago, so I believe the problem is caused by a recent change.

I made an attempt to find recent related changes. This commit seems to touch code related to sanitizing a .url in a filename:

And the following two security advisories deal with filename sanitization or with .url files specifically:

But I may be barking up the wrong tree.

Whoops, looks like I reversed the "Actual results" and the "Expected results".

The Bugbug bot thinks this bug should belong to the 'Firefox::File Handling' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → File Handling

Hello, thank you for the bug report!
Managed to reproduce on:

  • Firefox 112.0;
  • Nightly 113.0a1;

Tested and reproduced on:

  • Windows 10;
  • Ubuntu 22;

Could not reproduce on macOS 12.
Setting as NEW so the developers can have a look.

Ever confirmed: true

I expect this is a regression from bug 1809923 or bug 1810793 (security fix to address .url file downloads being saved and used to read/open arbitrary files) but I would have thought that the result would be that we'd save, not that nothing gets saved at all. It may be that because the sanitized name is not equal to the input name, the extensions API rejects the save (code example), - but that seems like a bug to me.

It's worth noting that at least one of the exploits from those sec bugs used an extension so we cannot "just" let extensions always save arbitrary .url files, I guess... But it seems fine to allow .download suffixes for cases like this.

From looking at the add-on, creating these shortcuts is the "whole point" of this extension, so the .download suffix would not be very helpful for that. I don't know that there's a good way to enable this that doesn't reopen the original security issues for webextensions. I suppose that's a question for the webextension team.

Component: File Handling → General
Keywords: regression
Product: Firefox → WebExtensions
Regressed by: 1810793

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

:enndeakin, since you are the author of the regressor, bug 1810793, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Flags: needinfo?(enndeakin)
Flags: needinfo?(enndeakin)

:willdurand could you take a look?

Flags: needinfo?(wdurand)
Severity: -- → S3
Priority: -- → P2
Whiteboard: [addons-jira]
Flags: needinfo?(wdurand)

I use QuickCut addon several times each day.
Since Firefox doesn't support downgrade, I kindly ask you to restore addon functionality by fixing this bug ASAP.
To say more, I've registered on Bugzilla just to ask about that.
Of course, for some people the security is more important than functionality.
So I suggest to add a boolean preference to about:config page, which enables/disables saving of .url files. The default value is up to you.

Linux when saving .desktop files is also affected.
ff 114.0.1 (64-Bit) Ubuntu

:neildenkin any investigation on this, as you were the assignee of the regressor?

As comment 5 describes, I think this is a question for the extensions team.

Flags: needinfo?(enndeakin)

(In reply to Neil Deakin from comment #11)

As comment 5 describes, I think this is a question for the extensions team.


Will, is there anything the webextension team needs to make this actionable? And/or do you know what needs to happen but do you need someone else to do it because you don't have time to do so? Is S3 appropriate given the pinging from relman and affected users? (not intended to be a leading question, "yes" may be the right answer!)

Flags: needinfo?(wdurand)

For my part as the reporter: the above QuickCut extension now allows saving redirecting html files with a custom name pattern. So I have migrated my workflow/scripts to use *.qc.html files, to differentiate them from other html files. This workaround has solved the problem for me and I'm guessing satisfies the security issue.

Please note:
Thе icons for *.html and *.qc.html files look the same (at least in Windows File Explorer), while the icon for *. url files looks different (has an arrow in the bottom left).
Unfortunately, it's not possible to set different icons for *.html and *.qc.html, because only the last extension matters.

Besides, when shortcut name is long, the extension name gets hidden in UI.
This is also the case when the width of the Name column in file manager is not wide enough.

Thanks for suggested workaround, but as for me, I cannot consider it as suitable.

Let me repeat my point. Take a look at file manager screenshot.

As you can see, there is no way to distinguish between the saved HTML page and HTML shortcut, while URL shortcut is distinguished clearly from both of them at the first glance (by the arrow at the bottom left corner).

That's why it's so important to fix this bug—to make Firefox comfortable for everyday use.

Meanwhile, I have to make 15 (fifteen!) mouse clicks to copy URL template, inserting a new URL into it, and rename the shortcut. It's VERY inconvenient!

So, please, fix the bug ASAP.

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