80579 - We call CommonFileDialog with spaces in the lpstrFilter parameter and use "*" instead of "*.*" for all files

Status: VERIFIED FIXED

(Core Graveyard :: File Handling, defect)

Description

[Jungshik Shin]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9) Gecko/20010505
BuildID:    2001050515 (m 0.9)

File|OpenFile does not resolve a shortcut (.lnk) to its target
folder if the shortcut is a 'link' (.lnk) to the network folder
(fileshare). Instead, Mozilla just opens '*.lnk' file and
shows the blank page. 

  On my Windows ME desktop, I have the shortcut named 
'jungshik on 192.168.0.1' whose target is 
'\\192.168.0.1\jungshik'. (192.168.0.1 is a linux box
on a local network running Samba. I guess it should not
matter whether it's a Linux box running samba server 
or a Windows box offering fileshare) When I try to open a file
with File|OpenFile (CTRL-O) with 'all type' and double-click
on 'jungshik on 192.168.0.1', Mozilla 'opens' it and shows
me the blank page instead of opening the 'directory' and 
showing me the list of files/directory to choose from. 

This does not happen if the type of the file to open
is NOT 'all type' BUT one of several offered (html, text,
xml, image). 

Reproducible: Always
Steps to Reproduce:
1.Make a shortcut to the shared file (on MS-Windows network)
  (e.g. 'mydoc on laptop' of which target is 
   '\\laptop\mydocuments') 
2.Bring up FileOpen dialog box either with File|OpenFile
   or by pressing CTRL-O keyboard shortcut.
3. Set the type of files to open to 'all files'
   (with other file types selected, this does NOT happen)
4. Try to open the 'directory' ('mydoc on laptop')


Actual Results:  Mozilla 'opens' 'mydoc on laptop' as if it's an actual file
and shows the blank page.

Expected Results:  Mozilla should resolves the shortcut 'mydoc on laptop' 
to '\\laptop\mydocuments' and opens it up as a 'directory'
and should show the list of files/directories.

Comment 1

[Asa Dotzler [:asa]]

*** Bug 90808 has been marked as a duplicate of this bug. ***

Comment 2

[benc]

Are you saying that ALL .lnk files break, or just some types?

Comment 3

[Jungshik Shin]

Pls, look at my original report. I thought this was clear enough....

-----------------
File|OpenFile does not resolve a shortcut (.lnk) to its target
folder if the shortcut is a 'link' (.lnk) to the network folder
(fileshare). Instead, Mozilla just opens '*.lnk' file and
shows the blank page. 
----------------

Local shortcuts(pointing to folders on the same computer as Mozilla is
running) work just fine. 

Comment 4

[Jungshik Shin]

I'm sorry I was testing Mozilla under Windows 2000 when I added the
last comment of mine. Apparently, under Windows ME (where I found
the problem in the first place), both shortcut to Network fileshare
and shortcuts to local folders AND files do NOT get resolved by
Mozilla(20010723). Therefore, your
change to summary was valid and I'm setting that back to what you
set. BTW, I have to make it clear that I haven't tested yet the latest
nightly build yet. 

Comment 5

[Jungshik Shin]

I've just confirmed it with 2001092703 build under Windows ME.
The shortcut to network file share is opened as if it's
a regular file with .lnk type so that actual files in that
network file share are not navigatable/selectable as I originally
reported.

In case of shortcuts to local folders/files, Mozilla complains
that it cannot find the file although targets of shortcuts
are valid. 

Comment 6

[benc]

->file handler?

Comment 7

[Doug Turner (:dougt)]

necko has the APIs to do this.  Over to file handling.

Comment 8

[Tony Tovar]

I believe you are referring to shortcuts that use UNC-type network reference; it
works fine with DOS-based shortcuts, e.g. drive F on Netware networks.  You
might want to update the Summary to mention that, e.g. "File/Open: .LNK
shortcuts to UNC don't work".

BUT...
It works-for-me with build 2002-04-02(03) on WinNT.

P.S. For another file-handler issue, see my new enhancement-request bug 135020

Comment 9

[Matthias Versen [:Matti]]

*** Bug 135020 has been marked as a duplicate of this bug. ***

Comment 10

[timeless]

*** Bug 135020 has been marked as a duplicate of this bug. ***

Comment 11

[timeless]

*** Bug 135020 has been marked as a duplicate of this bug. ***

Comment 12

[Tony Tovar]

Here's a related issue (from dupe bug 135020):

In the Save As dialog, LNK files are correctly recognized as links to new folder
locations but the original filename is rewritten, i.e., "download.zip" becomes
"shortcut to Downloads.lnk"

This is an issue on WinNT (if not all Windows OS versions) with the latest
build, 2002-04-04.

Comment 13

[Ere Maijala (slow)]

Actually, I think that in the case of a shortcut to a folder, the correct action
is for the open or save dialog to follow the shortcut (WFM).

Unfortunately I cannot reproduce the original issue or the related one from
comment #12 on my systems (Windows 2000 Workstation and Server), build 20020410.
Tried shortcuts to local and remote folders (UNC path) and files.

Comment 14

[Matthias Versen [:Matti]]

*** Bug 139016 has been marked as a duplicate of this bug. ***

Comment 15

[Boris Zbarsky [:bzbarsky]]

*** Bug 140776 has been marked as a duplicate of this bug. ***

Comment 16

[Ian Pottinger]

I'm seeing a serious variation of this bug. I reported it as bug 14077 which has
been Dup'ed to this.  I think this variation warrents immediate attention and
possible block the release of Mozilla 1.0

Dup'ed bug 14077
----------------
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+)
Gecko/20020426
BuildID:    2002042608

When I double click on a file or directory shortcut (.lnk) to navigate to the
file I want to open, the Open File dialog changes to a Save File As dialog. 
(Very strange, very unnerving, and potentially very destructive!)

Reproducible: Always
Steps to Reproduce:
1. Create a file or directory shortcut (.lnk) file
2. Double click on the shortcut in the File > Open File ... dialog

Actual Results:  The dialog with title "Open File" disappears and is replace
with a new dialog with title "Enter name of file to save to..."

Also note that the currently displayed directory has change to the default
directory regardless of where the shortcut pointed.

Expected Results:  Double click on a directory shortcut should move you to that
directory. You should should remain in the Open File dialog.

Double click on a file shortcutshould move you to the directory containing that
file.  You should should remain in the Open File dialog.

Comment 17

[Tony Tovar]

Ian,
Sorry but I can't duplicate this on my copy.  I'm running the 2002-04-29 branch
on WinNT.  I tried various types on .LNK files (local, network, files,
directories) without a problem.

Also, I confirmed that this version works correctly on Win2000 (Server, SP2) for
both the original File/Open report and for my File/Save As report; Save As is
still broken on NT.

Since this is clearly OS-dependent, the question becomes: Can we program around
it, or does Mozilla lose control once it calls the file dialog boxes?

Comment 18

[Ian Pottinger]

Tony:  I've just downloaded the 2002042908 trunk build on to a winNT4 and a
winXP box.  I was not able to reproduce either versions of the bug on the winNT4
box.  It seems to be fixed.  However, the problem as discribed in bug 14077
still exists!!

Should bug 14077 be reopened??

Comment 19

[Ian Pottinger]

Sorry ... to clearify, the problem as discribed in bug 14077
still exists *under winXP*!!

Comment 20

[Ere Maijala (slow)]

*** Bug 142638 has been marked as a duplicate of this bug. ***

Comment 21

[Ere Maijala (slow)]

Reporter of bug 142638 sees this only when adding an attachment. Interesting,
need to try it.

Comment 22

[Tony Tovar]

Should there be a separate META tracking bug for these issues?  We're starting
to get lots of different OS-specific examples mixed together on this bug.

WinME: comment #1 re File/Open treats link as data-file; comment #20 (bug
142638) re Mail/Add Attachment treats link as file selection

WinNT: comment #8 (bug 135020) re File/Save As follows link but changes filename

WinXP: comment #16 (bug 140776) re File/Open changes to Save As
---------------------

Ian, can you confirm (re your comment #18) that you are unable to dupe the NT
problem?  I suspect you tried one of the WinME cases rather than the NT testcase.  

Comment 23

[Ian Pottinger]

Tony, you are right.  I didn't properly test the NT bug.

Anyway, using build 2002050904 i confirmed that:
STILL TRUE: WinNT - File/Save As follows link but changes filename
STILL TRUE: WinXP - File/Open changes to Save As

Sorry. can't comfirm the WinME bug since I recently changed that box to Linux
:-)  Can't test linux since I still learning how to use it. :-(

Comment 24

[Sam Katz]

What we are seeing with the latest milestone (RC3) is not that the dialog 
changes, rather the same behavior with a new result. Before, it would display a 
blank page if you tried to open the .ink file, now it tries to save it. Note 
that this is an acceptable behavior for an executable file type, although 
acceptable behavior would be not to accept a non-browser file type at all, and 
produce an error message based on extension. (This is beyond the scope of this 
bug.)

Comment 25

[Jesse Ruderman]

*** Bug 151962 has been marked as a duplicate of this bug. ***

Comment 26

[Sam Katz]

confirmed on nightly 20002061408 9:02 PM CST. (1.0 alpha warranted a new look).
As a user, it makes sense to have a cross-platform file manager (or file picker
in this particular bug.) I was going to test with Meow (the current vapor
project at http://meow.mozdev.org), only to find out that it was vaporware (that
is it has no binaries, or clearly accessible source code (at least from my
perspective.)

Go Meow! (no insults intended, I am not a programmer.)

Comment 27

[R.K.Aa.]

*** Bug 133290 has been marked as a duplicate of this bug. ***

Comment 28

[Sam Katz]

My purpose of this post: Mozilla 1.1 (20020820008)
I do not view this as a showstopper, but do not understand why somebody with a
large heart does not add a parsing routine for .ink files.. it does lower
mozilla's use on windows me, and it would be nice to have a browser that worked
nicely across all OSes which we support..

Note that by support I mean that our distributions support. I am not critizing
in order to create enemies, only to provoke discussion. 

I have not learned enough about programming to be able to write this routine myself.
Sam

Comment 29

[Ere Maijala (slow)]

Sam,
Mozilla uses Windows' common dialog when opening a file. Mozilla just opens the
dialog and waits until the dialog is dismissed. Therefore it is up to Windows to
handle the navigation and parsing of shortcut files. Now, for some unknown
reason this does not always work. I've tried to find a reason for this, but
unfortunately it works correctly for me in my development environment. I may
take another shot at it when I have time.

Comment 30

[timeless]

ok a few points.
1. you guys still haven't completely documented the behaviors (by os, by
feature, by steps)
2. when it changes from open to save that probably means that it opened and then
didn't recognize the file in which case it tried to save it.

i've been playing with this on windows2000,
steps:
file>open file...
click history

i see the following (slightly modified, names and paths obscured, note that i'm
using tabs, and it seems mozilla has some issues with tabstops+japanese characters)
listed in filepicker	filenameondisk		target
x$ on foopy		x$ on foopy.lnk		\\foopy\x$
desktop.ini		desktop.ini (2).lnk	x:\program\winzip\desktop.ini
にほんご בּת.txt		にほんご בּת.txt.lnk		x:\desktop\にほんご בּת.txt
WinZip			WinZip.lnk		x:\programf\winzip
WINZIP32.EXE		WINZIP32.EXE (3).lnk	x:\programf\winzip\winzip32.exe
chrome			chrome.lnk		x:\chrome
VOLUME (X:)		VOLUME (X).lnk		x:
163705.jpg		163705.jpg.lnk		x:\desktop\163705.jpg
bookmarks.html		bookmarks.html.lnk	x:\desktop\bookmarks.html

ok, so that's the easy bit.
now the fun stuff, clicking on things and not getting too confused by pictures.

WinZip looks like a program but is actually a shortcut to a folder which has the
winzip icon specified in desktop.ini
chrome is a shortcut to a folder and looks like it too (wow)
volume and x$ are shortcuts to drives/shares and look like what they are.

clicking on any of these thing (w2k as ts - mozilla 2002081908) selects them
without changing the filename in the filepicker (open).
double clicking them opens that folder.

clicking any of the other things listed puts the filename (as shown in the
second collumn) into the filename field.

surprisingly enough, the *same* behavior happens when i use notepad's file>open.
i'm really upset about this bit, afterall, how can i fix a bug when there's no
inconsistency with a native application?

ok, now the hard part. saving. this is hard because i really don't want to ruin
any of the files i have ...

ok, let's skip that for a moment. This is cute, when i select a shortcut to a
folder, windows changes the button from 'Save' to 'Open' and when i select a
shortcut to a file, it's back to 'Save', hrm, windows is giving me a hint.

as for how we actually handle shortcuts, as mentioned in comment 7, we do have
an api to handle resolving a .lnk file so while comment 28 is right, we don't
have one for .ink files (i'm not sure i have any .INK files, but that's ok, it's
our fault for not supporting them), but it was not very nice of that commenter
to make me waste my morning testcasing this bug and missing breakfast based on
an assertion which is wrong (we do have the code, we even said we had the code).

ok, let's start with easier stuff -- i still don't want to destroy any files.

ok. first observation, you can't rename files in the history folder from
explorer or a common dialog. ... this makes life hard for me.

ok, steps:
create a file (i used right click. new>text document), name it 'test.txt', we'll
be using notepad to destroy it, so you don't really want it to have important
data in it. for convenience, stick it into your recent folder (if you created it
in the recent folder using the context menu, you'd have a hard time renaming it,
just like i did, so stick is a move/cut).

now if you're lucky, windows will automatically make a test.txt.lnk file for
you. i'm not sure when it had the time to do that, but it did it for me, so
we'll skip that step.

practice saving files:
1. run notepad
2. type some gibberish (i recommend copying text from bugzilla, it's a good
source of gibberish)
3. file>saveas
*. switch to UTF8 encoding if you're using NT, you wouldn't want the nice
japanese and hebrew characters to be destroyed, would you?
4. click history
5. find test.txt (not the shortcut, the one that doesn't have the shortcut)
6. select it
7. click save
7' you're prompted to confirm saving since test.txt already exists
8. click yes

by this time you should have a test (2).txt.lnk file, we're not concerned about
where it came from. but i have one.

9. repeat steps 3-4.
10. find test.txt (the shortcut, not the file, it should have a shortcut icon)
11. repeat steps 6-8.

for reference:
 3,661 test.txt
   527 test.txt.lnk
   527 test.txt (2).lnk
so you might want to check file sizes occasionally to make sure that you never
manage to actually save *into* the .lnk file itself.

12. run mozilla (ok, it was probably already running, but perhaps you were using
something else to read this bug, like Eudora)
13. load this bug
14. do step 3
15. select text file (we don't want webpages, they're dangerous and messy creatures)
16. do steps 4-8

17. do steps 9-11 following any rule variations required from 14-16. (iow save
over test.txt.lnk)
i'm not using this bug (i'm using the results of filing bug 163891)
my results:
4,787 test.txt
  527 test.txt.lnk
  527 test.txt (2).lnk
notice that i have yet to manage to destroy the .lnk file. hrm, this is getting
hard.  what does it take to actually do anything interesting for this bug?

18. ok well, this isn't working. so pretend step 8 was really 8a.
8b. in another navigator window
8c. file>open
8d. click history
8e. do steps 5-6
8f. click open

19. pretend step 11 was really 11a
11b. do steps 8b-8d
11c. do step 10
11d. do step 6
11e. do step 8f

20. pretend step 16 was really 16a
16b. do 8b-8f

21. pretend step 17 was really 17a
17b. do 11b-11e

if at any point in this wonderfully convoluted test sequence you get some
behavior you didn't expect, i'd like to know, it'd actually be useful
information so you are welcome to comment in this bug. however be sure to
include at least: full os name/version [Windows2000 Advanced Server - this
should be servicepack 2, but i'm not certain] (and any remoting software you're
using [eg VNC] i'm using Remote Desktop Connection from windows XP) and the full
mozilla useragent (javascript:navigator.userAgent) [Mozilla/5.0 (Windows; U;
Windows NT 5.0; en-US; rv:1.1b) Gecko/20020819] if you happen to have a buildid,
that's nice [2002081908] since it gives us the hour field which userAgent doesn't.

ok, the results i got were all predictable, i never actually managed to save any
text into a file named test.txt.lnk, the fact that i managed to get that
filename to appear in the filename field is a feature of windows. I'm not
concerned about it.

the next steps actually demonstrate bugs
22. drag test.txt.lnk to mozilla

expected results:
A. load test.txt 
B. its path to appear in the location field.
actually results:
Save dialog box.

Now, why is it that we got this dialog box? because
A. nowhere early in file handling did we resolve the shortcut
B. by the time mime parsing got the file, it didn't know what to do with this
binary stream and so it offered to save it.

Somewhere in bugzilla is a bug about the fact that it never makes sense to offer
to save a local file. Obviously any user intending to /copy/ a file would use a
file manager (Explorer, Meow, whatever).

I think that we should probably handle .lnk files at Drop and Open (in the event
someone tries to run |mozilla test.txt.lnk|)

At this point, unless someone really feels some strong desire for file handling
to own this bug, it probably belongs to Drag and Drop.

If you have questions or comments and need help contacting me, I should be
available on irc.mozilla.org #mozilla as timeless.  Emailing my bugmail account
is not welcomed and not useful.

IMO this bug should have been dead by comment 13.

Comment 31

[Sam Katz]

Timeless,

1. I have never downloaded mozilla source, I was just asking why we couldn't
parse .ink files, I sincerely apoligize if I have confused you.

You have not wasted your morning, as a matter of fact, you have seemed to prove
remarkably that you can in some circumstances (as eres said) reproduce the bug
on w2k as well as windows me. (this was not previously possible.. see comment 
3() 
I do want to point out that there are two different OSes here.. I have both
windows me and w2k on two different machines.. and will run your testcases in
detail if you wish.
3. .Ink files should never be destructible.. and are not in my simple open and
saving tests under windows me.. although the strange paths are disconcerting.

Eres,
I am wondering what enviroment you are running.. timeless seems to think we can
support such parsing..using existing code. But we would need testcases.. I am
willing to help in this regard if ever *anybody* need it.
Sam

Comment 32

[Ere Maijala (slow)]

Even if we could do it, what good would it be to parse a link to, for example,
some network directory? It's .LNK (as link), btw.

Comment 33

[timeless]

oh right. for those of you using pre w2k dialogs, clicking history is hard.

the history button is part of the places toolbar default button set.
clicking it changes your current directory to the "Recent" folder, which is what
you see in start>documents. to get there on w9x/nt<5 you should be able to
(unless you've really customized your system)
A. should work unless recent and desktop aren't siblings:
1. select the desktop (alt-i, down, home)
2. select filename (alt-n)
3. type: ..\recent<enter>

B. desktop was moved:
1. A2
2. type: c:\windows\recent<enter>

if recent isn't there then your windows is customized (my w98se is slightly
customized, but B works for me, my w2k is still stock) you can either search for
it (it should have lots of .lnk files) or play guessing games -- or you might be
able to make a new profile (start>shutdown>logoff, enter a new name, login).

C. recent was moved:
you know where you put it ;-)

Note that the *only* way i could reproduce this bug was using drag and drop. the
common dialogs *never* failed me.

Comment 34

[Jungshik Shin]

timeless,
> 1. you guys still haven't completely documented the behaviors (by os, by
> feature, by steps)

  Maybe not completely documented are all sorts of strange behaviors, but
what I described in my original bug report is still the case(as
of Mozilla 1.1b) under
Windows ME. (I'll reboot to Windows 2k and try there). Below is
what I wrote reproduced for your reference although it's right at
the top of this bug. 


------------------
Reproducible: Always
Steps to Reproduce:
1.Make a shortcut to the shared file (on MS-Windows network)
  (e.g. 'mydoc on laptop' of which target is 
   '\\laptop\mydocuments') 
2.Bring up FileOpen dialog box either with File|OpenFile
   or by pressing CTRL-O keyboard shortcut.
3. Set the type of files to open to 'all files'
   (with other file types selected, this does NOT happen)
4. Try to open the 'directory' ('mydoc on laptop')

Actual Results:  Mozilla 'opens' 'mydoc on laptop' as if it's an actual file
and shows the blank page.

Expected Results:  Mozilla should resolves the shortcut 'mydoc on laptop' 
to '\\laptop\mydocuments' and opens it up as a 'directory'
and should show the list of files/directories.
---------------

This problem does not exist if 'save as' is used instead of 'open'. 


As for opening a shortcut to a _local_ folder/file, I've also confirmed
a strange change from 'open' to 'save as'. I suggest that a separate bug
be filed for this behavior(related to opening shortcuts to
locale files/folders) and that this bug be restricted to 
opening a network file share.  I should have suggested that
rather than agreeing to the change of the summary line
in comment #4. 

Comment 35

[Jungshik Shin]

The problem described in comment #34 (and in my orignial bug report) does not exist
under Windows2k. That's why I set the OS to Windows ME when I filed this bug. 
As is well known, Win2k and WinME are two completely different OS'. 


In 24 hours, I'm going to change the summary line to 'file/open a network file
share does not
work' and file a separate bug for 'opening shortcuts to local
files/folder' unless I hear some objections against it. 
 

Comment 36

[timeless]

ok, i just tested win98se, nothing unexpected happened. fwiw the drag and drop
issue is new since 093 (it was broken in 094) -- I'm working on getting enough
bugs/changelogs together to get it fixed.

i tested \\raistlin\f$ and \\192.168.2.1\f$, as well as \\raistlin\plugins and
\\192.168.2.1\plugins. all of them worked correctly for both open and saveas.

please don't file random bugs just because you think someone else is
experiencing something. doing that wastes everyone's time.

you haven't indicated whether this problem happens in notepad. please do so.

Unless you can prove that we're incorrectly using the API and that Notepad
behaves differently, i'm going to blame winme and/or your winme.  as such we'll
mark this bug invalid and move on with life. (our job is to behave like notepad.)

it works on w98, it works on w2k, winme is end of lifed, and there's no evidence
that we're incorrectly using the file apis.
the codepath that we take for winme/win98 is here:
http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsFilePicker.cpp#365
  ofn.Flags = OFN_NOCHANGEDIR | OFN_SHAREAWARE | OFN_LONGNAMES |
OFN_OVERWRITEPROMPT | OFN_HIDEREADONLY;

the codepath that we could take for win2k is here:
http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsFilePicker.cpp#163
   ofn.Flags = OFN_NOCHANGEDIR | OFN_SHAREAWARE | OFN_LONGNAMES |
OFN_OVERWRITEPROMPT | OFN_HIDEREADONLY;

they're identical (in fact i don't think we actually take the unicode codepath
yet, it's a hypothetical idea which we're aiming for at some future time). the
only interesting flag which could cause problems is:
OFN_NODEREFERENCELINKS which you can see we don't use:
http://lxr.mozilla.org/seamonkey/search?string=OFN_NODEREFERENCELINKS

here's the winapi reference just to prevent you from claiming you're too lazy to
look for it:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/UserInput/CommonDialogBoxLibrary/CommonDialogBoxReference/CommonDialogBoxStructures/OPENFILENAME.asp

so you only need to read 2 pages, both relatively short. if you can find any
problem in our code (link 1) based on the reference (link 2) then you can
quickly get this bug resolved. if not then it's probably not our fault.

if a problem occurs during a windows api call and we don't make any mistakes in
setting up that api call, and it doesn't happen on current windows (say 2k/xp)
[it doesn't even happen on other windows (98se)] then it's really not our fault.
 We're about to resolve a macosx(10.x : x<2) bug as invalid because it was an os
bug which was fixed by apple for 10.2 (jaguar).

Please do find out if the problem comes from samba.  Simple tests include using
\\127.0.0.1\c$ and \\127.0.0.1\share.

I do agree with the reporter that the summary was mistakenly changed. So here's
my proposed summary, if the reporter feels i erred then the reporter can change
it, but i don't think i have.

Comment 37

[Jungshik Shin]

> please don't file random bugs just because you think someone else is
> experiencing something. doing that wastes everyone's time.

I don't what you meant here. I filed a bug because I experience
the problem myself. 


> you haven't indicated whether this problem happens in notepad. please do so.

I haven't indicated that explicitly(which is my mistake), but do you think 
I was such a fool as you seem to think that I hadn't tested it with Notedpad and 
MS IE before reporting the bug??? The same is true of Samba testing
you suggested. 

Notepad/wordpad under Windows ME does NOT have this problem period. 
Neither does MS IE 5.x/6 under Windows ME. The relevance
of MS IE not having this problem may be a bit less than
that of Notepad/wordpad not having this problem because MS IE 
may possibly use a different API. 

BTW, when you tested Mozilla/Notepad under Win 98SE, did you
set the type of files to open to 'all files'? Mozilla
does not have this problem unless it's set to 'all files'
as I wrote in my original bug report and comment #34.

--------
3. Set the type of files to open to 'all files'
   (with other file types selected, this does NOT happen)
--------- 


> Unless you can prove that we're incorrectly using the API and that Notepad
> behaves differently, i'm going to blame winme and/or your winme.  as such we'll
> mark this bug invalid and move on with life. (our job is to behave like notepad.)

  Now, is it sufficent??  The fact that both Notepad
and MS IE 5.x/6 does NOT have this problem under Windows ME
precludes  your hypotheses - Samba's fault, WinME's fault - from 
being the case.  

> our job is to behave like notepad.

 Sorry, but I beg to disagree. I'm pretty sure Mozilla includes
work-arounds for bugs of OS. Of course, bugs which require
work-arounds for OS bugs  should be given low priorities than other bugs 
for which  Mozilla is directly responsible. However, I wouldn't
go as far as to say 'out job is to behave like notepad'. 
 


Off-topic: 

> here's the winapi reference just to prevent you from claiming you're too lazy to
> look for it:

  I'm afraid this kind of attitude and language makes Mozilla's bugzilla 
rather an unfriendly place to end users who don't know much
about programming.(when I first reported the bug,
I had zero-experience with Win32 programming last May. That should not,
however, prevent me from reporting what I thought and
still think a legitimate bug).  I've received several complaints from
Korean users of Mozilla that  Mozilla-bugzilla is  a less  
friendly (and more cathedral-like) place than gnome-bugzilla.
Needless to say, there are a number of friendly and helpful people
here, but sometimes(not always) some people appear to 
scare off some end-users.      

Anyway,  I can take a look at WinAPI and I'll do. However,
I can't debug it under Windows ME because my WinME partition
is too small to install VC6++ and ohter mozilla build environment.
 
 

Comment 38

[Jungshik Shin]

This is really strange. 
I've just installed OpenOffice 1.0.1 under Win ME and it doesn't have
the problem Mozilla has. I also took a look at their file picker
code. The way GetOpenFileName()(WIN API call) is invoked 
in OO is different
(with different OPENFILENAME flags set) from the way it's
invoked in Mozilla, but the difference
does not seem to be significant enough to 
cause the problem Mozilla has. Well, who knows what strange things
are going on in Windows ME...

   

Comment 39

[Sam Katz]

edit number 28-First of all, this bug does not deal with .ink files, and I am
extremely sorry for the typo. Saving is the correct action for such files, if
they exist. I'm sorry.. but this is the same old bug: I meant .LNK files.

Comment 40

[Sam Katz]

OK. I have run pieces of timeless's testcase (timeless or anyone trying his
testcase-please see notes.) on the 8/22 build and I have been able to define the
behavior under Windows ME and how it differs from standard windows behavior
Mozilla:
1. File menu-->Choose File
2. Select All Files from Files of Type. .lnk shortcuts are displayed.
click on a folder shortcut (local) (an interesting note, order of files gives
folder shortcuts no priority)
3. Behavior: Mozilla tries to open the file instead of passing it to windows
(api, see previous comments) Mozilla, realizing the file type isn't supported, 
displays a save dialog. (this all happens transparently..the open dialog changes
to a save dialog.) User must click *open* before the dialog changes. There is no
filename in the filename field.
OR:
Select HTML Files under Files of Type from the Choose File dialog.
It correctly displays the folder the shortcut points to. (an interesting note,
folder shortcuts have priority.)

In notepad/wordpad, selecting All Files does not displays folder shortcuts
without priority, (it shows them with priority when other types are selected)
but still displays targets correctly. (I need more people to test this.. I got
inconsistent results..once, it didn't display shortcuts in all files mode..)

we still need to know.. whether network shortcuts exhibit the different or same
behavior and under what OSes, and *we need to change the summary accordingly.. 
In summary: all files is treating shortcuts differently than in native
applications.. can we add all files to the summary?

--
notes for timeless:
could you clarify why recent was used in your testcase.. 
 paths are not visible to me through history.. except through properties. Could
you provide specific instructions here, as the same is true on w2k, and they are
complete..

*2 it turns out that there is some anomaly in tweak ui. History sometimes refers
to C:/windows/history, which is not viewable from the open dialog of both
notepad and mozilla. However, once it is located in the memory or top level of
the open dialog, it should refer correctly to C:/windows/recent. If anybody has
any desire to diagnose, and/or report this possible tweak ui bug, please e-mail
moz23[atthingy]paperlessconscience.com for details.

in response to timeless's <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=80579#c30">Comment 30</a> I
have attempted to run his testcase under Windows Me.. using the 8/22 build
(2002082208)

1. The ''history'' feature in the "places" bar of W2k is not in windows me. I am
using  .lnk files on desktop. One is local (regular shortcut to My Documents),
and one is on network**. C:\Windows\Recent is equalivent..one can try adding it
via tweak ui.*2
**both shortcuts were saved instead of opened, my network is currently
inaccessible. Does this indicate that .lnk files are not being parsed at all
under winme? It should have returned an error..unless as noted in comment 1, all
files are not selected.. (for instance select "HTML Files" and bug disappears.) 
Mozilla under Windows Me does not put the filename in the filename field and the
Open dialog still says "Open". In notepad, the filename field  in the open box
only references filename, not folders or .lnk. 
  
 

Comment 41

[Jungshik Shin]

Thank you for your testing.

> we still need to know.. whether network shortcuts exhibit the different or same
> behavior and under what OSes,

 I've conducted some more experiments under Win ME since last night.
The behavior of a shortcut to a network share originally
reported and confirmed by me and you  is always reproducible
provided that the shortcut is  in Desktop. I also confirmed
what you described  
in comment #40 and in earlier comments (turning of 
'open to save as' when 'all' filetype is selected
and a shortcut to a local folder is double-clicked
in open dialog box). 

 A new fact is that a shortcut to a network fileshare
behaves the same way as a shortcut to a local filefolder
IF it's inside another file folder instead of Desktop. 

All these anomalies are not observed with Mozilla under Windows 2k.
Neither are they observed with Notepad/Wordpad/OpenOffice
under Windows ME.  I also took a look at OpenOffice's 
file picker code for Windows. It's different from Mozilla's,
but couldn't pinpoint which difference makes this observed
difference in behaviors of two. Even more strange is
that Win98SE does not have these problems. It would
make more sense if both Win ME and Win98SE behaved
identically. 

Another try I'll make is apply all critical updates
to my copy of WinME and see if that makes any difference.



I'll also try to make some
changes in Mozilla's file picker code, but testing it
is not so easy because I don't have Mozilla build environment
for Win ME. (i have to build it under Win2k and package
it to install under WinME) 

 
> and *we need to change the summary accordingly.. 
> In summary: all files is treating shortcuts differently than in native
> applications.. can we add all files to the summary?

  Given the above, I'm not sure whether we have to have two separate
bugs, or just one with a new summary line you proposed. 

Comment 42

[Sam Katz]

All you have said makes perfect sense, except for the special properties of the
desktop..

"A new fact is that a shortcut to a network fileshare
behaves the same way as a shortcut to a local filefolder
IF it's inside another file folder instead of Desktop. "

Note that my shortcut to my documents is a regular shortcut (the special one was
removed). Or maybe you are talking about a target that is on the desktop to
begin with..

My suggestions for patching this issue:
Transparently change filetype to "HTML Files" and then back to all files when
the directory is navigated to, all within the .lnk function.. (I had the idea
after posting my testcase.) 

Comment 43

[Jungshik Shin]

> "A new fact is that a shortcut to a network fileshare
> behaves the same way as a shortcut to a local filefolder
> IF it's inside another file folder instead of Desktop. "

Let me try again. I have shortcuts to '\\192.168.0.1\jungshik'
on Desktop(say, shortcut1) and in two regular folders in C:
(say, shortcut2 in C:\dir1\shortcut2, and C:\dir2\shortcut3).

In Mozilla file-open dialog box, if I double-click shortcut1,
Mozilla 'displays' 'shortcut1.lnk' instead of resolving it
into and navigating into '\\192.168.0.1'. This is what I reported
last May and confirmed later.

However, shortcut2 and shortcut3 (although they both point
to the same target as shortcut1) behave differently from
shortcut1. When I double-click them in Mozilla file-open
dialog box, 'open' turns to 'save as' and the content
of the target directory (\\192.168.0.1\jungshik) is
displayed with 'shortcut2.lnk'('shortcut3.lnk')
as the default filename. This behavior is identical
to that of shortcuts to local folders. 

Again, both of these symptoms only occur with filetype
set to all. Can you confirm this difference between
shortcut1 on one hand and shortcut2/shortcut3 on the other hand?
 
 
> My suggestions for patching this issue:
> Transparently change filetype to "HTML Files" and then back to all files when
> the directory is navigated to, all within the .lnk function.. 

  Well, we don't have that fine-grained control. We just
invoke a Win32 API function GetOpenFileName() with 
OPENFILENAME struct filled out. Once we call GetOpenFileName(),
what happens in File Open Dialog is completely up to Windows
until 'open' or 'cancel' is clicked or a regular file
(neither a folder nor a shortcut to a folder, local or remote)
is double-clicked on. What's driving me kinda 'nut'
is that somehow double-clicking on 'shortcuts'
(to a folder) doesn't make 'common file open dialog' (see
MSDN document for which timeless gave the URL) behave
as they're supposed to ONLY under Windows ME
and ONLY when 'all' filetype is selected. This is supposed to be
taken care of by Windows provided that Mozilla 
invokes GetOpenFileName() the way it's supposed to,
which seems to be the case (although it's different
from the way OpenOffice does). 

Anyway, I'll try a couple of different OPENFILENAME
flags, build Mozilla under Win2k, and test my build
under WinME to see if they make any difference. I would
already have done this, but my build failed a couple
of times because I was not familiar with a new
build procedure under Win2K. (I used to use 'nmake'
build procedure not supported any more.)
 

Comment 44

[Sam Katz]

In response to <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=80579#43">Comment 43</a>:
thanks for clarifying, but I am unable to confirm that there is any difference
in behavior between network shortcut (placed on the desktop, like you) and a My
documents shortcut, and another shortcut in c:\downloads.

They both change to save as. In case it helps, I am using Windows ME 4.90.3000
with  IE 6, fully updated. (in case the open dialog changes with an IE update..
and the build was provided because I was curious whether we had slightly
different builds.

Tommorow, I will download and test the latest nightly.

Comment 45

[Ere Maijala (slow)]

Attachment: Possible fix

Looks like the filter string is causing trouble on some shell versions. For me
this happened on one WinXP system, but not Win2K. This patch will change All
Files filter * to *.* and strip the whitespace (MSDN says that the pattern
string should not contain spaces). I'd like you guys to try it out so we could
see if it helps.

Comment 46

[Jungshik Shin]

Thank you for the patch. The patch definitely works. 

At long last, I was able
to build a Windows binary of Mozilla with a new build
method and I've just tested it under both Win2k
and WinME. Under Win2k, it worked fine as before.
And under WinME, it worked without a problem
in opening both a shortcut to a network share
and a shortcut to a local folder. 

Why don't you ask for review? 

Comment 47

[timeless]

lpstrFilter
Pointer to a buffer containing pairs of null-terminated filter strings. The 
last string in the buffer must be terminated by two NULL characters. 
The first string in each pair is a display string that describes the filter 
(for example, "Text Files"), and the second string specifies the filter pattern 
(for example, "*.TXT"). To specify multiple filter patterns for a single 
display string, use a semicolon to separate the patterns (for 
example, "*.TXT;*.DOC;*.BAK"). A pattern string can be a combination of valid 
file name characters and the asterisk (*) wildcard character. Do not include 
spaces in the pattern string.

fwiw, I filed bug 164489.

Comment 48

[timeless]

Comment on attachment 96549 [details] [diff] [review]
Possible fix

change:
+    if (!nsCRT::strcmp(filter.get(), NS_LITERAL_STRING("*").get()))

to
if (filter.Equals(NS_LITERAL_STRING("*"))

Comment 49

[Ere Maijala (slow)]

Attachment: Patch v2

Fixed the string comparison. Also changed
    filterBuffer[len] = NULL;
    filterBuffer[len+1] = NULL;
to
    filterBuffer[len] = '\0';
    filterBuffer[len+1] = '\0';

Comment 50

[Ere Maijala (slow)]

Timeless, could you review the additional changes also? Thanks.

Comment 51

[tor]

Comment on attachment 96586 [details] [diff] [review]
Patch v2

sr=tor

Comment 52

[Ere Maijala (slow)]

Fix checked in to trunk.

Comment 53

[sairuh (rarely reading bugmail)]

rs vrfy

Comment 54

[u60234]

*** Bug 169496 has been marked as a duplicate of this bug. ***