GNOME Bugzilla – Bug 554712
FF3 - Can't select and edit prior filename before save in Print to File dialog
Last modified: 2018-04-15 00:07:32 UTC
Please describe the problem: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.1) Gecko/2008070400 SUSE/3.0.1-0.1 Firefox/3.0.1 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.1) Gecko/2008070400 SUSE/3.0.1-0.1 Firefox/3.0.1 The FF3 print to file dialog on Linux does not allow you to select and edit an existing filename (.pdf or .ps) before saving new document. I was advised that this is a GTK issue and that this was the proper bugzilla to address it. The FF3 print dialog is, for lack of better words, incredibly awkward. On many occasions I need to print a set of pdf files from the federal court sites. The needed pdf file names are fairly detailed and are a series similar filenames. The new print dialog in FF3 makes this so awkward I want to scream. The filenames will be of the type: Case-2008_cv_00318-Dailey-Vs-Caterpillar_Motion-SummaryJudgment.pdf Case-2008_cv_00318-Dailey-Vs-Caterpillar_Motion-SummaryJudgment_Exhibit-A.pdf Case-2008_cv_00318-Dailey-Vs-Caterpillar_Motion-SummaryJudgment_Exhibit-B.pdf Case-2008_cv_00318-Dailey-Vs-Caterpillar_Motion-SummaryJudgment_Exhibit-C.pdf Case-2008_cv_00318-Dailey-Vs-Caterpillar_Motion-SummaryJudgment_Exhibit-D.pdf In FF2, we were presented with a normal save dialog that easily allowed selecting the directory, selecting a filename to place it in the filename edit field, changing a character or two and saving normally. Now in FF3, the effort is doubled. The new cryptic dialog requires first navigating the "Save in folder" directory listbox, then after choosing "Other" you are presented with a somewhat normal file dialog to navigate to the desired directory only to find that there is no way to select a file. (the file side of the dialog is all grayed out -- see screenshot below) Then after choosing "Open" to select the directory, you are returned to the print dialog to enter a new filename in a completely separate filename textbox. That's nuts. Then you get to try and remember "was that filename?: " Case-2008-cv-00316_Dailey-Vs-Caterpillar-Motion_SummaryJudgment_Exhibit-B.pdf or was it: Case-2008_cv_00318-Dailey-V-Caterpillar_Motion-SummaryJudgment_Exhibit-B.pdf This makes saving a series of files with complex, but similar, filenames incredibly tedious and awkward where before it had been a simple matter of point & click. Steps to reproduce: Reproducible: Always Steps to Reproduce: 1.File -> Print or (ctrl+p) 2.choose "Print to File" 3.Navigate to desired save directory and try to choose old filename. Actual results: Actual Results: Inability to select prior file name an have it placed in the filename edit textbox Expected results: Expected Results: Ability to select an existing filename placing it in the filename editbox then the ability to change a few characters and save Does this happen every time? Yep! Other information: screenshot: http://www.3111skyline.com/download/screenshots/moz/firefox_print3.png Originally filed with mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=454329 It was suggested that bugzilla.gnome was the right place to file by an openSuSE list member: It's probably better reporting this to Gnome's bugzilla I think. The print dialog is mainly the Gtk one with just small customizations in Firefox' usage. Probably one of our Gnome guys can comment on that? Wolfgang
I don't print much. But I agree very much that printing to a file is a rather awkward process. And yes, it's a Gtk issue and not Firefox' fault. I don't know who invented this interface, maybe there was a reason for separating the folder and file in this unusual way? Natural would be, for me, to have a file chooser button that actually selects a file to save to.
The idea has always been to turn the entry in the print dialog into a GtkFileChooserEntry, giving us filename completion.
You mean a new entry widget with built-in filename completion? I could think of something like an entry with an embedded button, which is something you often see in Win32 applications. I would personally prefer a file chooser button which *also* completes, although you do need to open it first. Incidentally some time ago I had the idea of a gtk setting that turns file chooser buttons into an entry like what I described above, to meet both use cases in the same widget, but never pursued it. Maybe that would help here if there is a conflict in different workflows?
Not a new widget, I mean the GtkFileChooserEntry widget that has been used in GtkFileChooser since forever.
Hm... I wasn't aware that the entry in the file chooser has that name, I guess I never really had to bother since it doesn't exist elsewhere. Still, I'd like your opinion about my comment. I don't think using a virtually new widget (file chooser aside) here is very attractive. I don't usually expect to type filenames in some entry and even less to suddenly see filename completions.
> I don't usually expect > to type filenames in some entry and even less to suddenly see filename > completions. And yet, thats exactly what happens in a file chooser dialog in save mode...
Using GTK+3 programms such as EOG and Gedit it looks like this is now fixed in GTK+3. Looks like a candidate for backporting to GTK+2 for consistency
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new