Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Lolu chungechunge lwabekwa kunqolobane. Uyacelwa ubuze umbuzo omusha uma udinga usizo.

URL Drag-and-Drop into Windows File Explorer shortcut sometimes fails

  • 5 uphendule
  • 1 inale nkinga
  • 2 views
  • Igcine ukuphendulwa ngu AliceWyman

more options

Hello, This issue may be related with "[meta] Implement URL parser per URL Standard", opened 9 years ago(!), but updated only 1 month ago (bugzilla). If somehow applicable, just let me know that my issue is already being taken care. Thank you.

D&D a Firefox URL into Windows File Explorer, may fail. Just try it for yourself (Firefox for Windows, version 102):

Will fail (notice the additional folder created): D&D on this URL will fail

Will fail and may even create an invincible 0 byte file (Windows is unable to delete it...): D&D this URL will also fail

Won't fail: D&D this URL will *not* fail


I only noticed this wrong behavior in version 102.0 (Firefox 64-bit for Windows) but, as I use this D&D functionality quite often, I don't believe this problem to have occurred much before 101.x. Only tested it in Windows though (Windows 10 Pro - 21H2 19044.1766, 64-bit). This thus seems to be a BUG introduced in version 101.x or 102.0

By trial & error, I think I eventually found out what is leading the D&D to eventually fail: it's related with the web page title (i.e., the Firefox tab title). This behavior has nothing to do with the URL value itself.

When D&D an URL into File Explorer, the URL shortcut name is supposed to be created with the webpage title. However, Windows filenames have some unsupported characters: \ / : * ? ” <> |

So, I guess Firefox should first parse this title and remove all these unsupported characters (or replace them with, e.g., “-“), before assigning the title to the shortcut name (a .URL file). Which, as I understand it, is not happening anymore. I have not found any issue with the URL value itself.

In fact, the D&D result may vary, depending on the characters the webpage name includes.

If it contains a “/”, it will create one (or more) Windows folders before creating the URL shortcut. E.g., if I D&D a webpage URL into “C:\my URL shortcuts folder”, with title “CAT5E Shielded 3/50μ Gold-Plated”, it will create a shortcut (with the correct link) in C:\my URL shortcuts folder\CAT5E Shielded 3\50μ Gold-Plated.URL Obviously, even though the URL content is right, this is not the expected behavior!

More troublesome can be a webpage title that contains a “:”, because it creates a 0-byte no extension file which sometimes (but not always) refuses to be deleted by Windows. E.g., if I D&D a webpage URL into “C:\my URL shortcuts folder”, with title “ShinobiHub – Article: How to Update”, it will create a zero-byte file in “C:\my URL shortcuts” folder with name “ShinobiHub – Article” (no extension). Trying to remove the file in File Explorer may display the error message: “Item not found. This is no longer located in <PATH>. Verify the item’s location and try again.”

[BTW, after some digging I find out how to remove the file: Just open a DOS window and type: del "\\?\C:\my URL shortcuts folder\ShinobiHub - Article " No need to restart or do anything else, just need to put \\?\ before the directory when using the del command. Also use the tab button to make sure the name is correct; sometimes a space is added at the end that can be easily missed.]

Strangely enough, a “Verified by: Cloudfare” (or something similar) is also display just below Firefox Url.

I’m not sure about the effect of other different unsupported file name characters. Anyway, this was tested in 2 different Windows computers, both with same faulty results. The same operation in Chrome works as expected.

Conclusion: This issue should be easy enough to find but I could not find any *recent* report on a similar issue. That makes me wonder… is this really a bug?... Please help. Thank you. Cecilio

Hello, This issue may be related with "[meta] Implement URL parser per URL Standard", opened 9 years ago(!), but updated only 1 month ago ([https://bugzilla.mozilla.org/show_bug.cgi?id=906714 bugzilla]). If somehow applicable, just let me know that my issue is already being taken care. Thank you. D&D a Firefox URL into Windows File Explorer, may fail. Just try it for yourself (Firefox for Windows, version 102): Will fail (notice the additional folder created): [https://www.aliexpress.com/item/1005004153128122.html?spm=a2g0o.productlist.0.0.5be2356dY4h1dY&algo_pvid=914493e2-21f2-4c96-84f0-5a4a199dc369&algo_exp_id=914493e2-21f2-4c96-84f0-5a4a199dc369-31&pdp_ext_f=%7B%22sku_id%22%3A%2212000028215225556%22%7D&pdp_npi=2%40dis%21EUR%21%2111.92%21%21%21%21%21%402101e9d116532551697874774e7ee1%2112000028215225556%21sea D&D on this URL will fail] Will fail and may even create an invincible 0 byte file (Windows is unable to delete it...): [https://hub.shinobi.video/articles/view/LTVqL3I8f8kIzsX D&D this URL will also fail] Won't fail: [https://bugzilla.mozilla.org/show_bug.cgi?id=906714 D&D this URL will *not* fail] I only noticed this wrong behavior in version 102.0 (Firefox 64-bit for Windows) but, as I use this D&D functionality quite often, I don't believe this problem to have occurred much before 101.x. Only tested it in Windows though (Windows 10 Pro - 21H2 19044.1766, 64-bit). This thus seems to be a BUG introduced in version 101.x or 102.0 By trial & error, I think I eventually found out what is leading the D&D to eventually fail: it's related with the web page title (i.e., the Firefox tab title). This behavior has nothing to do with the URL value itself. When D&D an URL into File Explorer, the URL shortcut name is supposed to be created with the webpage title. However, Windows filenames have some unsupported characters: \ / : * ? ” <> | So, I guess Firefox should first parse this title and remove all these unsupported characters (or replace them with, e.g., “-“), before assigning the title to the shortcut name (a .URL file). Which, as I understand it, is not happening anymore. I have not found any issue with the URL value itself. In fact, the D&D result may vary, depending on the characters the webpage name includes. If it contains a “/”, it will create one (or more) Windows folders before creating the URL shortcut. E.g., if I D&D a webpage URL into “C:\my URL shortcuts folder”, with title “CAT5E Shielded 3'''/'''50μ Gold-Plated”, it will create a shortcut (with the correct link) in C:\my URL shortcuts folder'''\'''CAT5E Shielded 3'''\'''50μ Gold-Plated.URL Obviously, even though the URL content is right, this is not the expected behavior! More troublesome can be a webpage title that contains a “:”, because it creates a 0-byte no extension file which sometimes (but not always) refuses to be deleted by Windows. E.g., if I D&D a webpage URL into “C:\my URL shortcuts folder”, with title “ShinobiHub – Article: How to Update”, it will create a zero-byte file in “C:\my URL shortcuts” folder with name “ShinobiHub – Article” (no extension). Trying to remove the file in File Explorer may display the error message: “Item not found. This is no longer located in <PATH>. Verify the item’s location and try again.” [BTW, after some digging I find out how to remove the file: Just open a DOS window and type: del "\\?\C:\my URL shortcuts folder\ShinobiHub - Article " No need to restart or do anything else, just need to put \\?\ before the directory when using the del command. Also use the tab button to make sure the name is correct; sometimes a space is added at the end that can be easily missed.] Strangely enough, a “Verified by: Cloudfare” (or something similar) is also display just below Firefox Url. I’m not sure about the effect of other different unsupported file name characters. Anyway, this was tested in 2 different Windows computers, both with same faulty results. The same operation in Chrome works as expected. Conclusion: This issue should be easy enough to find but I could not find any *''recent''* report on a similar issue. That makes me wonder… is this really a bug?... Please help. Thank you. Cecilio

Isisombululo esikhethiwe

For the record, this was fixed in the Firefox update to version 102.0.1 which was released yesterday. Release notes: http://www.mozilla.org/firefox/102.0.1/releasenotes/

Funda le mpendulo ngokuhambisana nalesi sihloko 👍 0

All Replies (5)

more options

Yes, this is a bug that has been fixed for Firefox 103.


Possible bookmarklet to sanitize the title. With this version you can set a replacement for each character you want to sanitize via a JSON {"key":"value"} pair.

javascript:/*sanitize pagetitle*/(function(){var ot=document.title,t=ot.replace(/[\\\/\:\|\?\*<>"]/g,r=>""+{"\\":"_","/":"_",":":"_","|":"_","?":" ","*":" ","<":"[",">":"]","\"":"'"}[r]).trim(); t=window.prompt('Original:\n'+ot+'\nSanitized:\n'+t+'\n\nEdit Title and click OK to Confirm',t); if(t)document.title=t;})()

more options

Ok, thanks for your fast response. I will look forward for Firefox 103 :-)

more options

Isisombululo Esikhethiwe

For the record, this was fixed in the Firefox update to version 102.0.1 which was released yesterday. Release notes: http://www.mozilla.org/firefox/102.0.1/releasenotes/

more options

AliceWyman said

For the record, this was fixed in the Firefox update to version 102.0.1 which was released yesterday. Release notes: http://www.mozilla.org/firefox/102.0.1/releasenotes/

I've done some (minor) tests. It indeed seems to be fixed now. Thank you!

more options

You're welcome. Thanks for the update on Firefox version 102.0.1. I'll mark it as the solution.