Closed
Bug 80579
Opened 23 years ago
Closed 22 years ago
We call CommonFileDialog with spaces in the lpstrFilter parameter and use "*" instead of "*.*" for all files
Categories
(Core Graveyard :: File Handling, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.2alpha
People
(Reporter: jshin, Assigned: emaijala+moz)
References
Details
Attachments
(1 file, 1 obsolete file)
1.35 KB,
patch
|
timeless
:
review+
tor
:
superreview+
|
Details | Diff | Splinter Review |
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.
Updated•23 years ago
|
Target Milestone: --- → Future
Are you saying that ALL .lnk files break, or just some types?
Summary: File/Open does NOT resolve a shortcut to the network folder(fileshare) → File/Open: shortcut(.lnk) does not open original file.
Reporter | ||
Comment 3•23 years ago
|
||
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.
Summary: File/Open: shortcut(.lnk) does not open original file. → File/Opne does NOT resolve shortcut to the network folder(fileshare)
Reporter | ||
Comment 4•23 years ago
|
||
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.
Summary: File/Opne does NOT resolve shortcut to the network folder(fileshare) → File/Open: shortcut(.lnk) does not open original file
Reporter | ||
Comment 5•23 years ago
|
||
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 7•23 years ago
|
||
necko has the APIs to do this. Over to file handling.
Assignee: dougt → law
Component: Networking: File → File Handling
QA Contact: benc → sairuh
Comment 8•22 years ago
|
||
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•22 years ago
|
||
*** Bug 135020 has been marked as a duplicate of this bug. ***
Comment 10•22 years ago
|
||
*** Bug 135020 has been marked as a duplicate of this bug. ***
Comment 11•22 years ago
|
||
*** Bug 135020 has been marked as a duplicate of this bug. ***
Comment 12•22 years ago
|
||
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.
Assignee | ||
Comment 13•22 years ago
|
||
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•22 years ago
|
||
*** Bug 139016 has been marked as a duplicate of this bug. ***
Comment 15•22 years ago
|
||
*** Bug 140776 has been marked as a duplicate of this bug. ***
Comment 16•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
Sorry ... to clearify, the problem as discribed in bug 14077 still exists *under winXP*!!
Assignee | ||
Comment 20•22 years ago
|
||
*** Bug 142638 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 21•22 years ago
|
||
Reporter of bug 142638 sees this only when adding an attachment. Interesting, need to try it.
Comment 22•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
*** Bug 151962 has been marked as a duplicate of this bug. ***
Comment 26•22 years ago
|
||
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•22 years ago
|
||
*** Bug 133290 has been marked as a duplicate of this bug. ***
Comment 28•22 years ago
|
||
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
Assignee | ||
Comment 29•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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
Assignee | ||
Comment 32•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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.
Summary: File/Open: shortcut(.lnk) does not open original file → Open CommonFileDialog is not resolving shortcuts(.lnk) to network folders(samba?)
Comment 37•22 years ago
|
||
> 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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
> "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•22 years ago
|
||
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.
Assignee | ||
Comment 45•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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.
Assignee: law → ere
Summary: Open CommonFileDialog is not resolving shortcuts(.lnk) to network folders(samba?) → We call CommonFileDialog with spaces in the lpstrFilter parameter and use "*" instead of "*.*" for all files
Attachment #96549 -
Flags: review+
Attachment #96549 -
Flags: needs-work+
Comment 48•22 years ago
|
||
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("*"))
Assignee | ||
Comment 49•22 years ago
|
||
Fixed the string comparison. Also changed filterBuffer[len] = NULL; filterBuffer[len+1] = NULL; to filterBuffer[len] = '\0'; filterBuffer[len+1] = '\0';
Attachment #96549 -
Attachment is obsolete: true
Assignee | ||
Comment 50•22 years ago
|
||
Timeless, could you review the additional changes also? Thanks.
Status: NEW → ASSIGNED
Attachment #96586 -
Flags: review+
Assignee | ||
Updated•22 years ago
|
Target Milestone: Future → mozilla1.2alpha
Comment 51•22 years ago
|
||
Comment on attachment 96586 [details] [diff] [review] Patch v2 sr=tor
Attachment #96586 -
Flags: superreview+
Assignee | ||
Comment 52•22 years ago
|
||
Fix checked in to trunk.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 54•22 years ago
|
||
*** Bug 169496 has been marked as a duplicate of this bug. ***
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•