Closed Bug 472488 Opened 15 years ago Closed 15 years ago

Default filename not used in non-save mode on Linux

Categories

(Core :: Widget: Gtk, defect)

All
Linux
defect
Not set
major

Tracking

()

VERIFIED FIXED

People

(Reporter: bzbarsky, Assigned: ventnor.bugzilla)

Details

(Keywords: platform-parity)

Attachments

(2 files, 1 obsolete file)

See bug 374011 comment 87.  I looked at the gtk2 nsFilePicker.cpp, and it doesn't use the default filename provided in modes other than "save".  It should, to actually implement the nsIFilePicker API.
I would have thought this patch would fix it, but the filepicker completely ignores this setting (including not even highlighting this file!).
Flags: wanted1.9.2?
Keywords: pp
For open dialogs you need to use gtk_file_chooser_set_filename() instead. I'm not sure what the effect is on relative paths or non-existent files, though.
Michael, could you roll a patch for this?
Attached patch Patch (obsolete) — Splinter Review
With the way the GTK dialog behaves, this will have no effect unless the filename given exists in the requested folder. If it does exist, it will be preselected and the the filename filled in the textbox.

I also decided to fix some little errors I found in the code. Its much easier to read now that we got rid of all that ridiculous dynamic linking.
Assignee: nobody → ventnor.bugzilla
Attachment #355899 - Flags: superreview?(roc)
Attachment #355899 - Flags: review?(roc)
Attachment #355899 - Flags: superreview?(roc)
Attachment #355899 - Flags: superreview+
Attachment #355899 - Flags: review?(roc)
Attachment #355899 - Flags: review+
Keywords: checkin-needed
Whiteboard: [needs landing]
Pushed 48e090c98118
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [needs landing]
This doesn't work over here (FC9, Firefox trunk build with this patch).  Just load the attachment page for this bug, select a file to attach, then click the file control's "browse" button again.  That file doesn't end up selected in the resulting filepicker...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Hmm, this is because we don't change directories to the last one you were in. If your file is in the directory that is first opened when you reopen the file picker, the file is selected.
> Hmm, this is because we don't change directories to the last one you were in.

Er, that would be a bug if it happened, no?  The file control certainly tells the filepicker to open the parent directory of the currently selected file.

But in any case, that's not what I'm seeing.  I end up with the right directory.  I just don't see the right file selected.
I'm doing a new approach now. That patch did introduce the bug I was seeing because GTK "helpfully" changes directories when you use that function (but since we don't have a directory in that default name GTK always goes to the pwd).
Should we be setting the filename by concatenating the dir and leafname, then?
Yep, I have a working patch for that now. I just need to wrestle with hg to update to tip :(
Attached patch Patch 2Splinter Review
This applies on top of patch 1.
Attachment #355899 - Attachment is obsolete: true
Attachment #356053 - Flags: superreview?(roc)
Attachment #356053 - Flags: review?(roc)
Attachment #356053 - Flags: superreview?(roc)
Attachment #356053 - Flags: superreview+
Attachment #356053 - Flags: review?(roc)
Attachment #356053 - Flags: review+
Keywords: checkin-needed
Whiteboard: [needs landing]
Pushed 5300ca58f128
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [needs landing]
Looks great.  Thank you!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.