1774683 - Bookmark shortcut creation by dragging to Windows File Explorer and dropping is partially broken

Status: VERIFIED FIXED

(Firefox :: File Handling, defect)

Description

[CKOTTMozillaBugzilla]

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

Steps to reproduce:

Example 1: Navigate to https://github.com/LibreCAD/LibreCAD, left-click and hold on padlock icon in URL bar, drag to File Explorer, release the mouse button.

Example 2: Navigate to https://learn.adafruit.com/quickstart-adafruit-io-wippersnapper, left-click and hold on padlock icon in URL bar, drag to File Explorer, release the mouse button.

Example 3: Navigate to https://www.google.com/, left-click and hold on padlock icon in URL bar, drag to File Explorer, release the mouse button.

Actual results:

Example 1: A folder named "LibreCAD" is created, and a zero-byte file named "LibreCAD" is created inside of the folder.

Example 2: Windows returns an error message: "Error Moving File or Folder/The filename, directory name, or volume label syntax is incorrect."

Example 3: A normal bookmark shortcut is created.

Expected results:

Normal bookmark shortcuts should have been created in all three examples.

It seems like the Firefox code for generating bookmark shortcut filenames from web page titles is not handling certain characters prohibited by Windows correctly.

Comment 1

[CKOTTMozillaBugzilla]

Affected system:

• Windows 10 Home 21H1 (OS Build 19043.1766)
• Running as admin did not fix the problem.
• System reboot did not fix the problem.

Comment 2

[CKOTTMozillaBugzilla]

Tested in Chrome: No problems.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 4

[Alice0775 White]

[Tracking Requested - why for this release]:Drag and drop of padlock creates broken internet shortcut

Regression window :
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b32ccff079ea010ad4adc466d76b6e99552fee58&tochange=b91422aa4ba10c7068a0b941f382d4c2ff423400

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

:enndeakin, since you are the author of the regressor, bug 1746052, could you take a look?
For more information, please visit auto_nag documentation.

Comment 6

[Neil Deakin]

Looks like the validation got lost when 1746052 was implemented.

Comment 7

[Neil Deakin]

Attachment: Bug 1774683, use ValidateFilenameForSaving to validate dropped links on Windows, r=mhowell

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/348482297427
use ValidateFilenameForSaving to validate dropped links on Windows, r=mhowell

Comment 9

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/348482297427

Comment 10

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for ESR102 approval when you get a chance.

Comment 12

[Neil Deakin]

Comment on attachment 9282025 [details]
Bug 1774683, use ValidateFilenameForSaving to validate dropped links on Windows, r=mhowell

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Dragging a link or image to the desktop where the filename contains invalid characters fails to drop the file. This is a regression.
• User impact if declined: The image does not drop on the desktop with no explanation as to why.
• Fix Landed on Version: 103
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): - Adds back functionality which was inadvertently removed.

• Windows only.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9282025 [details]
Bug 1774683, use ValidateFilenameForSaving to validate dropped links on Windows, r=mhowell

Approved for 102.1esr.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr102/rev/ddfb2c8160d4

Comment 15

[Giorgia Nichita, Release Desktop QA]

Reproduced the issues following the STR from Comment 0 on an affected Nightly build from 2022-06-16, on Win 10 x64.

Verified as fixed on Firefox 102.1.0esr (20220630021511 - treeherder) and Firefox 103.0b3 (20220629170104 - treeherder) on Win 10. The shortcuts are created in all three examples.

Comment 17

[Tom S]

Could we get this into a dot release maybe?

Comment 22

[Ruokola Pasi]

Honestly I don't think this fix can wait for the 103 release, and the fix for this should should be released as soon as possible (IMO, this alone should warrant a 102.1 release).

Comment 23

[jscher2000]

As a short-term workaround, users could pre-sanitize page titles before dragging using an add-on or script. I posted an example bookmarklet here (not a pretty interface, but it's just for a week or two I assume):

https://www.jeffersonscher.com/res/sumomarklets.html#saniTitle

Comment 27

[Pascal Chevrel:pascalc]

Neil, could you request uplift to mozilla-release? Thanks

Comment 28

[Pascal Chevrel:pascalc]

Comment on attachment 9282025 [details]
Bug 1774683, use ValidateFilenameForSaving to validate dropped links on Windows, r=mhowell

Approved for 102.0.1.

Comment 29

[Pascal Chevrel:pascalc]

https://hg.mozilla.org/releases/mozilla-release/rev/3ea3f23678fb

Comment 33

[Ciprian Georgiu, Desktop QA]

I've reproduced the issue on an affected Nightly build, 103.0a1 (20220616093051), with STR from comment 0.

The issue is verified as fixed on 102.0.1-build1 as well, running Win 10 x64.

Comment 34

[Vitaliy]

What about x86 version? I have 102.0 (32 bits) version. Cannot update because it's a last version. This issue is not fixed.

Comment 36

[Vitaliy]

102.0.1 (32 bits) - bug fixed!

Comment 37

[tettee.green]

fixed for most places, but I re-encountered the bug on 102.01 (64-bit)

top.document.title = "わひこ@C100土曜西さ13a on Twitter: "GHost9Solidのノウハウを生かした次回作案②「血〇〇法」、発覚されていない状態で敵に近づき特定のボタンを押すと血〇〇法のモーションが発動、首筋に柔らかい感触を感じ敵は××されてしまう https://t.co/gM552Fqmza\" / Twitter"

also found with
top.document.title = " "GHd触を感じ敵は××されてしまう https://t.co/gza\" / Tr----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------"

Seems to be related to title length.

Encountered on this twitter post (light nsfw) https://twitter.com/wahiko94/status/991253919534755840

Comment 38

[tettee.green]

(In reply to tettee.green from comment #37)

The formatting ate some of the backslashes on the inner quotes.
top.document.title = " \"GHd触を感じ敵は××されてしまう https://t.co/gza\" / Tr----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------"

Comment 39

[:Gijs (he/him)]

(In reply to tettee.green from comment #37)

fixed for most places, but I re-encountered the bug on 102.01 (64-bit)

Please file a separate bug with this information. Tracking another fix in the same bug causes confusion and likely causes missed release branches in terms of uplift.

(and for reference, bugzilla uses markdown, similar to github - you can enclose stuff in fences, ie triple backtick (`), to ensure no formatting is lost.)

Comment 40

[Pascal Chevrel:pascalc]

https://hg.mozilla.org/releases/mozilla-esr102/rev/e3ecaabccc15b700df25afe65cf4bdee763f4312 FIREFOX_ESR_102_0_X_RELBRANCH

Comment 41

[tettee.green]

(In reply to :Gijs (he/him) from comment #39)

(In reply to tettee.green from comment #37)
Please file a separate bug with this information. Tracking another fix in the same bug causes confusion and likely causes missed release branches in terms of uplift.
Done! https://bugzilla.mozilla.org/show_bug.cgi?id=1779128