266317 - Save as, webpage complete should not be a save dialog "filter"

Status: RESOLVED INCOMPLETE

(SeaMonkey :: Download & File Handling, defect)

Description

[Christopher Aillon (sabbatical, not receiving bugmail)]

Currently, save as complete is selected by a "filter" which is an abuse of
platform APIs as far as I've found (GTK, Windows, and OS2 at least agree with
this.  I couldn't find the macosx API in a quick search, but I'd imagine it
agrees as well).

On all platforms, we should be describing the type of filter the picker is
showing, e.g. "Text files", "HTML files", etc.  We do this for everything except
Save as HTML complete, which describes a different type of saving rather than a
specific filter.  This is counter intuitive.  Saving should save things
consistently.  The "save complete" functionality should move to either a new
menu item (with optional new keybinding) and potentially (dare I say it?) a pref
to make this the default save behavior for HTML files.

This seems like something though that will get wontfixed (sigh) but I figured
I'd throw it out there.

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

bug 116008 comment 61 also mentione the menu item suggestion in passing...

Comment 2

[Boris Zbarsky [:bzbarsky]]

Note that this is actually a tri-state.  We have "save complete", "save as
original HTML", "save as text" all selected by that dropdown.

So the pref approach won't really work, since that effectively disables "save as
text".

I agree that we need better UI for this; suggestions are welcome.  ;)  If I dare
ask, "what does IE do?"

Comment 3

[Matthias Versen [:Matti]]

Attachment: IE (5.0 german) + Mozilla screenshot

Comment 4

[Christopher Aillon (sabbatical, not receiving bugmail)]

(In reply to comment #2)
> Note that this is actually a tri-state.  We have "save complete", "save as
> original HTML", "save as text" all selected by that dropdown.

No, we have two *.html filters stomping upon each other.  The fact that we offer
saving as other types with other filters is negligent here.

> So the pref approach won't really work, since that effectively disables "save as
> text".

So the pref would be for the behavior of what Mozilla does when the HTML filter
is chosen in the save dialog.  The two options are to save as complete, or as
html only.  It won't have any affect on what happens when other filters are
selected.

Comment 5

[Boris Zbarsky [:bzbarsky]]

So if I want to choose between three save modes I'll have two separate pieces of
UI to do it with?  Sorry, but that's just as bad.  I thought your objection was
that using the filter affect the save behavior was an abuse of the api...

Comment 6

[Christopher Aillon (sabbatical, not receiving bugmail)]

My argument is that letting the user choose between "*.html" and "*.html" where
both do different things is bad.  We must have only one "*.html" item in the
filter list.  What happens after the user clicks OK is not really up to any
platform APIs, and is up to the application.

My preferred method of handling this is an extra menu option.  Do note that even
with that option, you are going to get the same exact dialog with one filter
that provides *.html, but does a Save as Complete instead of a traditional Save As.

Comment 7

[Holger Pollmann]

> My argument is that letting the user choose between "*.html" and "*.html" 
> where both do different things is bad.  We must have only one "*.html" 
> item in the filter list.  

How about adding an additional option to the save dialog? There could be two drop-down boxes:

 - scope: 
    * save complete webpage
    * save source only
 - format:
    * as HTML/XML
    * as plain text
    * as whatever

If "save complete webpage" would be chosen as scope, only those formats that allow such storage should be shown, i.e. "plain text" would not be an option then.

> My preferred method of handling this is an extra menu option.

That would clutter the menu further. While I agree that's a sensible option, integrating it into the save dialog is about as sensible - a user would first decide "I want to save this page" and then "I want to save it like this".

Comment 8

[Boris Zbarsky [:bzbarsky]]

> How about adding an additional option to the save dialog?

You sure the native filepickers support that sort of thing?

Comment 9

[Gary Houston]

I wanted to raise a new bug against the "Save As" dialogue, but this one seems to be on the same track.

When the dialogue first opens, there is no visible place to select the format of the saved document. Instead, this only appears if "Browse for other folders" is selected. This doesn't make much sense. If somebody is happy with the selected folder, they have no reason to select "Browse for other folders" and will never see the format choice.

After "Browse for other folders" has been selected, it's still not obvious that this is a selection of the file format for the saved file. It just looks like a not-very-useful filter for the file list. It has options like "Text Files" and "All Files", and what output format do you expect to get for "All Files"?

Perhaps a "native filepicker" has been used to make the implementation easier, but it seems that a custom dialogue would give a better result.

Comment 10

[Gary Houston]

Attachment: screenshot of Save As dialogue, Linux/gtk2

Comment 11

[Boris Zbarsky [:bzbarsky]]

There _is_ a custom dialog, that was used for the longest time.  People decided to switch to the native GTK dialog for "consistency".

There's a pref to keep using the custom dialog, if you want.  Set "ui.allow_platform_file_picker" to false.

Comment 12

[Gary Houston]

I see. The custom dialogue at least avoids the "Browse for other folders" problem on Linux/gtk2 (I don't know if the "native filepickers" do the same thing on other platforms.)

However it's still obviously a generic file picker dialogue, and uses a file filter to select the file type for saving, so it's not really much of an improvement.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Sure.  It doesn't solve this bug at all.

Comment 14

[Gary Houston]

It's worth taking a look at the save-as dialogues in other applications, e.g., in Gimp it seems to work OK. However in that case they select the file type from the file extension, and it couldn't deal with two different types of .html.

Comment 15

[Gary Houston]

However, in the Gimp, if you save as .jpg, a new dialogue appears with the specific options for saving a JPEG file, such as the quality setting. Something similar could be done for the HTML variants, and an extra dialogue would have the advantage of giving a place to explain the differences between "complete" and "HTML only".

Comment 16

[Cees T.]

The filter shows the current files of the type you want to save.

I don't see the problem, then again i also hate the GTK2 file picker.

We could extend the XUL file picker to include a scope setting so as an extra feature we can choose how to format source only and current source only.

Comment 17

[Tony Mechelynck [:tonymec]]

Attachment: Gnome2 file picker, quite different from the older one

Notice the filetype dropdown at bottom right (with names but no extensions) and the name box at the top. This might satisfy the OP.

Comment 18

[Tony Mechelynck [:tonymec]]

Attachment: XUL file picker

...in SeaMonkey trunk, with a different theme.

I prefer this one because it has a checkbox to show hidden files and folders. Its drop-down (at the bottom, part of the input box) is more old-fashioned but personally I like it too -- YMMV.

Comment 19

[Tony Mechelynck [:tonymec]]

Moving to Download & File Handling

Comment 20

[Phoenix]

With presence of XUL file picker, is this still actual?

Comment 21

[Phoenix]

Resolved per whiteboard