Closed Bug 78509 Opened 23 years ago Closed 20 years ago

Can't make an Internet shortcut with :, /, \ in title (by dragging link to desktop)

Categories

(SeaMonkey :: UI Design, defect, P3)

x86
Windows 2000
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: rhomolka, Assigned: bugzilla)

References

()

Details

Attachments

(2 files)

Suck.com has colons in most of their titles (maybe all).
Can't drag an Internet shortcute to the desktop, system barfs on colon.

Tested locally with other illegals, slash and backslash barf.
Other path-illegal characters (*, ?, ", <, >, |) get stripped.
Looks like an XP apps issue..
Assignee: asa → pchen
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps
Ever confirmed: true
QA Contact: doronr → sairuh
reporter: you didn't give steps to reproduce, that's not nice.

Did you use the file menu, or did you drag a link to explorer, or did you drag 
the url proxy to explorer, or ...?
Sorry about "steps to reproduce", I thought I was clearer.
If you drag something from the Loction bar to the desktop, it'll barf.  Dunno 
about other ways of making an Internet Shortcut.
*** Bug 97654 has been marked as a duplicate of this bug. ***
This looks like a dupe of bug 91122.  Someone should prolly make one a dup of
the other (this bug has a more concise summary).

Is there any progress in the works?  
*** Bug 91122 has been marked as a duplicate of this bug. ***
Can this get a few keywords, like polish and 4xp?  Not to nag, but this and the
window focus grabbing bug are the two top annoyances on my list.  
Summary: Can't make an Internet shortcut with :, /, \ in doc title → Can't make an Internet shortcut with :, /, \ in title (by dragging link to desktop)
*** Bug 60396 has been marked as a duplicate of this bug. ***
marking p3 and mozilla0.9.7
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9.7
Well well well, with winXP, starting around October 11 builds, I can
reproducably crash mozilla by trying to make one of these shortcuts
(http://www.thestandard.com/companies/industry/index/0,2059,6324,00.html is my
test URL).

The dialog pops up, and all of mozilla gets stuck.  I have to go to task manager
to kill mozilla, then the dialog is clickable and it goes away.  If it stays a
crasher, perhaps it should get higher priority.
Okay, I did a little more research on this.
The dialog comes up in winXP, not win2k.  Win2k just gives a beep when trying 
to make a shortcut.  WinXP gives the following error message: "The filename, 
directory, or volume lavel syntax is incorrect."

It seems to be a focus problem, because clicking on any mozilla window won't 
get you anywhere, but clicking on the desktop finally brings the dialog into 
focus where you can click ok and unlock mozilla.
*** Bug 105114 has been marked as a duplicate of this bug. ***
Bug 112395 looks like a duplicate of this bug

<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=112395">112395</a>
Not going to be able to get to this soon, pushing out to mozilla1.0.1
Target Milestone: mozilla0.9.7 → mozilla1.0.1
*** Bug 112395 has been marked as a duplicate of this bug. ***
You can also see this problem dragging bug 108704, which has the title "Mozilla
crashes when form is moved by JavaScript M096 & Trunk [@
nsGenericHTMLElement::GetPrimaryFrame]" (Note the colons).
-> default assignee
Assignee: pchen → trudelle
Status: ASSIGNED → NEW
Target Milestone: mozilla1.0.1 → ---
this is a really anoying bug, many people i know including myself drag links to 
their desktop.
Any chance of hitting it before 1.0?
->blaker for triage
Assignee: trudelle → blaker
please please please don't push this back.  This is the one and only bug that
really annoys the heck out of me on a daily basis.
Attached patch patchSplinter Review
Comment on attachment 67156 [details] [diff] [review]
patch

remove the PR_FREEIF (very very bad) and r=pink.
Attachment #67156 - Flags: review+
Fix checked in.

Some caring individual should file a bug on me to complete IE behavior by 
stripping off everything up until (and including) the last "\", which is IMO 
the best.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
I had a patch similar to this in bug 42009 (attachment 49717 [details] [diff] [review]).  There are three
differences, though.

1. I used strtok which should be faster than looping, shouldn't it?
2. My list invalid characters is longer.  I got that list from the MozClassic code.
3. I used a space instead of "-".  "-" is kinda ugly, dontchathink?
*** Bug 42009 has been marked as a duplicate of this bug. ***
comments on dean's patch:

1) you need to PR_free tempStr when you're done. Right now it is leaked.

2) The use of strtok really complicates reading of the patch, and all the
copying back to titleStr is un-necessary. I prefer the solution that just edits
the string in place.

3) at first i liked the longer list of invalid characters, but then I realized,
this is the 21st century and things like commas and questionmarks should be
perfectly valid in filenames.

what do the rest of you think? I can go either way.
The patch using strchr() is indeed better because it edits it in place.  

The formal list of characters that WindowsXP's Explorer shell disallows the 
user to put into a filename are:  \ / : * ? " < > |

The Question mark should not be used because it is a wildcard character.

This set differs from Dean's exclusion set only by not including ~ (tilde) 
and , (comma) which are both legitimately usable.
The invalid char under Windows are:
 
     \ It's the path separator
     : It's the drive letter delimiter
     / It's the command line option delimiter
   * ? Wildcards
     " Sometimes used to enclose long filenames
 < > | Shell redirection chars

Also any character bellow ASCII 32 is invalid.

 ~ and , are valid filename chars.

Related info
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q177506

A think attachment 67156 [details] [diff] [review] and attachment 49717 [details] [diff] [review] are both incomplete.
QA Contact: sairuh → tpreston
*** Bug 130181 has been marked as a duplicate of this bug. ***
I think this bug should be reopen. It is not completely fixed. To reproduce the
bug go to this URL:

http://bugzilla.mozilla.org/show_bug.cgi?id=94023

And try to create a shortcut by doing a drag and drop from the URL bar to the
desktop.

The following characters should also be checked also: * ? " < > | 



Reopening, additional characters need to be filtered:

   * ? Wildcards
     " Sometimes used to enclose long filenames
 < > | Shell redirection chars
any character bellow ASCII 32 is invalid.

http://lxr.mozilla.org/mozilla1.0/source/widget/src/windows/nsDataObj.cpp#494
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached file testcase
Verified fixed with Mozilla Build ID 2003091604
Can we get this closed?
It does seem to be fixed in at least Mozilla 1.5b according to my test with 
that testcase.

Does this URL represent the current source?
http://lxr.mozilla.org/mozilla/source/widget/src/windows/nsDataObj.cpp#516

If so, I still don't seem to see handling for several of those characters so 
perhaps it was fixed in some other method in an alternate way?
This has been fixed by the patch in bug 103468.
Would someone please verify this fixed and then mark closed.
marking fixed based on Brodie's comments
Status: REOPENED → RESOLVED
Closed: 23 years ago20 years ago
Resolution: --- → FIXED
Product: Core → Mozilla Application Suite
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: