In the Linux viewer, try "Debug Save", which brings up a file selection dialog with the filename set to the name of the current page (e.g. test0.html). Double-click on .. in the directory list, to move up one directory. The filename goes away -- now it's trying to save to a null filename (apparently). Now hit OK -- the app crashes (because the backend routines have no error checking for a bad filename -- I've filed a separate bug, 3023, on that). The filename should stay set even when the user changes directories.
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
changing to m7 as this isn't very important imho.
Summary: file selection dialog forgets filenames on chdir → [PP]file selection dialog forgets filenames on chdir
This may be a bug in the gtk file selection box; I've seen the same problem in other gtk apps.
Marking M8. If you plan to fix any of these for m7, mark them so.
this will require changing the file selection dialog a lot. (i'll do it. just later.)
Moving all Widget Set bugs, past and present, to new HTML Form Controls component per request from karnaze. Widget Set component will be retired shortly.
moving to XP Toolkit/Widgets since these are not HTML form controls
mass moving m14 bugs to m15
dividing up phillips bugs, he no longer works here
*** Bug 26203 has been marked as a duplicate of this bug. ***
Summary: [PP]file selection dialog forgets filenames on chdir → file selection dialog forgets filenames on chdir
*** Bug 24908 has been marked as a duplicate of this bug. ***
Adding the "dogfood" keyword attracted by bug 24908, "[ANNOYING] Changing directory CLEARS filename when downloading.", and cc-ing email@example.com, who was made owner of that bug.
jar says this behavior is present in 4.7 as well. PDT-
*** Bug 30932 has been marked as a duplicate of this bug. ***
*** Bug 29981 has been marked as a duplicate of this bug. ***
Pavlov removed the dogfood keyword, so I'm adding a beta2. It's really hard to do much involving saving or opening files until this bug is fixed -- really, the only way to use the current file selection dialog is to ignore the gui and type full pathnames into the text field. :-) (Hopefully someone will write an html fsb before beta2 and all these bugs will just go away.)
*** Bug 32403 has been marked as a duplicate of this bug. ***
*** Bug 33025 has been marked as a duplicate of this bug. ***
Depends on: 6783
Whiteboard: fixed -- waiting for 6783
Target Milestone: M16 → M15
actually, i havn't quite fixed this yet. it is a trival change now though.
No longer depends on: 6783
Whiteboard: fixed -- waiting for 6783
Mass-moving most M15 bugs to M16
Target Milestone: M15 → M16
Can we get a retest with the latest build please? Thanks!
Whiteboard: [RETEST NEEDED]
oh, yeah --this is still a problem. :-) [tested using 2000.04.27.09] pavlov, what's your status on this?
Hardware: PC → Other
Hardware: Other → PC
Whiteboard: [RETEST NEEDED] → [STILL HAPPENS]
This is still a problem: Save As in the editor and browser windows use the old file selection dialog, which has the problem, whereas Open File in the editor uses the new file selection dialog, which unfortunately has the same problem (plus a bunch of new layout-related problems). So simply hooking up the new dialog for Save As won't cure the problem, alas.
[nsbeta2+] please fix before 6/1
Whiteboard: [STILL HAPPENS] → [nsbeta2+] 6/1[STILL HAPPENS]
*** Bug 40165 has been marked as a duplicate of this bug. ***
*** Bug 40274 has been marked as a duplicate of this bug. ***
Mass-moving all dated nsbeta2+ bugs to M19
Target Milestone: M16 → M19
*spam*: transferring current XP Menu bugs over to jrgm, the new component owner. feel free to add me to the cc list (unless am the Reporter) of any of these, if you have any questions/etc.
QA Contact: sairuh → jrgm
ugh, these should go back to me...
QA Contact: jrgm → sairuh
This patch fixes the problem (in the xp filepicker). Basically, it uses this rule: If the user has clicked a file in the filepicker (and its name is in the textfield), then we clear that on a directory change. If the user has typed something in, we keep that on a directory change. This also changes the textfield to show just the filename (when you click on a file), instead of the whole path.
will this patch fix it for good? if so will it be in the next milestone or what?
Pavlov, can you review this patch when you get a chance?
I've got this one.
Assignee: pavlov → bryner
Status: ASSIGNED → NEW
Patch is now checked in.
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
Is this really fixed? I still get this consistently! :-/
This is fixed for the XP filepicker. The Open File menu item is still hooked up to the native filepicker.
I am still seeing this on the FTP download dialog for Linux build 2000060508. What is the XP filepicker anyways?
Can someone please list here the bugs for the various "Please change to use XP filepicker", so that we can all go join the cc lists for those bugs and find out when they're slated to be fixed? The fix for this bug doesn't actually help usability if it only fixed a dialog no one is using yet. Let's get everyone using the XP filepicker.
The main switchover bugs appear to be: Bug 36789, "File->Save should use nsIFilePicker instead of nsFileSpecWithUI", nsbeta2+ Bug 39234, "use nsIFilePicker instead of nsFileWidget in Editor", M17 Bug 37175, "bookmark code should use nsIFilePicker and nsILocaleFile from nsIFileSpec/nsIFileSpecWithUI", LATER Earlier work was done in bug 6783, "[feature] use nsIFilePicker to replace nsIFileWidget, nsIFileSpecWithUI, etc" File>Open File and File>Open Web Location>[Browse] should use nsIFilePicker too, if they don't already, but that's outside of the purview of this bug.
coolio. works using 2000.06.07.10 linux opt comm bits.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.