Closed Bug 80579 Opened 20 years ago Closed 18 years ago
We call Common
File Dialog with spaces in the lpstr Filter parameter and use "*" instead of "*.*" for all files
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.
*** Bug 90808 has been marked as a duplicate of this bug. ***
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.
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)
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
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.
necko has the APIs to do this. Over to file handling.
Assignee: dougt → law
Component: Networking: File → File Handling
QA Contact: benc → sairuh
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
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.
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.
*** Bug 139016 has been marked as a duplicate of this bug. ***
*** Bug 140776 has been marked as a duplicate of this bug. ***
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.
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?
Sorry ... to clearify, the problem as discribed in bug 14077 still exists *under winXP*!!
*** Bug 142638 has been marked as a duplicate of this bug. ***
Reporter of bug 142638 sees this only when adding an attachment. Interesting, need to try it.
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.
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. :-(
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.)
*** Bug 151962 has been marked as a duplicate of this bug. ***
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.)
*** Bug 133290 has been marked as a duplicate of this bug. ***
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
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.
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
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.
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.
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.
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.
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?)
> 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.
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...
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.
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.
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.
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.)
> "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.)
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.
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.
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?
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
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("*"))
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
Timeless, could you review the additional changes also? Thanks.
Status: NEW → ASSIGNED
Comment on attachment 96586 [details] [diff] [review] Patch v2 sr=tor
Attachment #96586 - Flags: superreview+
Fix checked in to trunk.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
*** Bug 169496 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.