Closed Bug 136619 Opened 23 years ago Closed 23 years ago

Redesign the unknown file type alert

Categories

(Core Graveyard :: File Handling, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

VERIFIED INVALID

People

(Reporter: mpt, Assigned: law)

References

Details

Attachments

(3 files)

This is son-of-bug 86640.

To reproduce:
*   Open the attached testcase.

What you see (regardless of whether bug 86640 has been fixed):
1.  A dialog, which should be an alert but isn't.
2.  The text `You have chosen to download a file...', which simply isn't true.
3.  Option buttons, which (a) are misused for choosing commands rather than
    options, and (b) require two clicks to choose an action when pushbuttons
    would require only one.
4.  An option `Open it' (if bug 86640 has been fixed) which is redundant, since
    if the appropriate program is known then the alert should never have
    appeared in the first place.
5.  A checkbox for `Always ask before handling files of this type', arranged
    in the opposite manner to how a user will think of it (asking a program to
    remember something makes more sense than asking a program to forget it).

What you should see:

,-----------------------------------------------------------------.
|:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
|-----------------------------------------------------------------|
|   .   The file "showattachment.cgi" is of type foo/bar, and     |
|  /!\  Mozilla does not know how to handle this file type.       |
|  """                                                            |
|       You can choose an application or plug-in to open the file |
|       with, or you can save it to disk.                         |
|                                                                 |
|       [/] Remember this _action for files of this type          |
|                                                                 |
|       (_Save... ) (View as _Text)   ( Cancel ) ((Open With...)) |
`-----------------------------------------------------------------'

On Windows, that's:

|       [[Open With...]] [ _Save... ] [View as _Text ] [ Cancel ] |
`-----------------------------------------------------------------'

(`View as Text' is bug 57342, and does not have to be implemented in order for 
this bug to be marked fixed.)

Problem occurs with:
*   Mozilla build 2002040508, Mac OS 9.2

Problem does not occur with:
*   Microsoft Internet Explorer 6.0 for Windows
*   Microsoft Internet Explorer 5.1 for Mac OS
Depends on: 86640
Attached file Testcase (Web page) (deleted) —
> 4.  An option `Open it' (if bug 86640 has been fixed) which is redundant,
> since if the appropriate program is known then the alert should never have
> appeared in the first place.

Unfortunately, this is not an option (at least on Linux).  The default "helper"
for PostScript files on all RedHat systems from 6.0 up to and including 7.2 is
"lpr".  This issue has been fixed in the current rawhide releases (the new
helper is gv) but that doesn't help with the existing OS releases.  Now if the
helper is lpr and the user tries to view a PS file, one of two things happens:

1)  The file is printed instead of being viewed
2)  Printing is not set up and we just silently fail (I plan to add an error
    dialog to the relevant code one of these days...)

Furthermore, even in the new world the user may not want to use gv as the app
and in those cases is likely to not have gv installed at all, thus coming back
to case #2 above
Oh, as a note bug 86640 is doing a lot of back-end work that should at least
make this design feasible.  So that really does need to get fixed before we do
this one.
Resolving INVALID.

I pointed out the folly of this proposal in bug 86640 and unless and until the
issues I raised there are addressed, this just makes no sense.

To re-iterate:  With this proposal, the first time I encounter, for example, a
file of type application/msword, I will get this dialog.

First, explain whether I will *always* get this dialog, or only if I don't have
a system that knows of MSWord?  If the latter, then that's wrong.  Our users
have been adamant that they will not permit us to open MSWord files without
prompting them.

So what happens when I see this dialog?  It doesn't have any way of suggesting
to the user that they might like to open it with MSWord, since that might be the
default for such files on their system.  That is not acceptable.

Secondly, it does not offer any way of even getting to MSWord save finding some
.exe file deep in the guts of c:\Program Files\Microsoft\Office\...  That is not
acceptable.

Thirdly, if the user decides to open the file with foobar.exe this time, but
wants the option to save to disk next time (or confirm, for safety's sake,
whatever), then they will uncheck the "Remember this action" box, and press
"Open With..." (and drill down to foobar.exe and press OK).  The next time they
encounter content of this type, they will see the same dialog and if they want
to open that file with foobar.exe too, then they have to press "Open With..."
and drill down to foobar.exe *again*.  That is not acceptable.

My conclusion is that this proposal is totally invalid.  It will remain so until
the unacceptable behaviors outlined above are fixed.  Your choice is to fix it
or assign the bug to somebody else.  That somebody won't ever be able to
implement this in Mozilla until such time as those issues are fixed, or I am no
longer in a position to have a say in the matter.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
The confusion in 4 is that while Mozilla can determine the appropriate 
application to use (operating system file association), it does not make sense 
for it to automatically launch it. Launching an app automatically based on the 
OS file association is a bad idea from a security standpoint and could lead to 
viruses or other inappropriate behavior, such as that indicated by Boris in 
comment #2. Perhaps this is more accurate:

|   .   The file "showattachment.cgi" is of type foo/bar, and     |
|  /!\  Mozilla does not automatically handle this file type.     |
|  """                                                            |

As for the default application, if there is a OS association, perhaps the Open 
With button could be a dropdown menu button. For example, for Microsoft Word

[[Open With v]]
| Microsoft Word    |
|-------------------|
| Choose Program... |

If the user picks a different app, it will be added to the list with the OS 
default. This is similar to the Open With right-click context menu in Windows 
2000.
I don't see any of these questions mentioned in bug 86640, but maybe I'm not 
reading it hard enough.

> First, explain whether I will *always* get this dialog, or only if I don't
> have a system that knows of MSWord?

You will get it if application/ms-word does not have a specified action in 
Mozilla's Helper Apps preferences on Windows and Linux, or the Internet control 
panel on Mac OS. Whether the OS's file manager is set to use MS Word for local 
.DOC files, or lpr for local application/postscript files, is completely 
irrelevant at this point.

> Our users have been adamant that they will not permit us to open MSWord files
> without prompting them.

So application/ms-word won't be in the default set of handlers, and nor will 
those users set up such a handler. Fine.

> It doesn't have any way of suggesting to the user that they might like to
> open it with MSWord, since that might be the default for such files on their
> system.  That is not acceptable.

That's not the job of this alert, it's the job of the application picker that 
they get when they click `Open With...'. If the OS knows about a default app 
for this type, it will be selected by default in the app picker.

Remember, as with any alert, you have about three seconds (plus or minus a 
second or so, depending on the user's mood) between the time this alert appears 
and the time the user clicks a button. If he doesn't grasp its contents 
sufficiently, the button he clicks will be chosen more or less at random, and 
he'll end up coming to ask me for help. The current dialog is about six or 
seven seconds worth, and the one in bug 86640 is (as I said) slightly worse.

> Secondly, it does not offer any way of even getting to MSWord save finding
> some .exe file deep in the guts of c:\Program Files\Microsoft\Office\...
> That is not acceptable.

It is also completely untrue, as you'll know if you've ever chosen `Open 
With...' in Windows Explorer, or double-clicked on a document with no creator 
code in the Mac OS Finder. It's an application picker, not a file picker.

> The next time they encounter content of this type, they will see the same
> dialog and if they want to open that file with foobar.exe too, then they have
> to press "Open With..." and drill down to foobar.exe *again*.  That is not
> acceptable.

That's not true either, because (a) it's an application picker, not a file 
picker, and (b) the previous choice is selected by default.

On a constructive note, I think Tim's suggested rewording is good.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
>I don't see any of these questions mentioned in bug 86640, but maybe I'm not 
>reading it hard enough.

http://bugzilla.mozilla.org/show_bug.cgi?id=86640#c21

>That's not the job of this alert, it's the job of the application picker that 
>they get when they click `Open With...'. If the OS knows about a default app 
>for this type, it will be selected by default in the app picker.

It *is* the job of this alert, because in the *real* world, there is no such
"app picker" that can be opened via your "Open With..." button.  What you see on
windows is a feature of Windows Explorer.  It is not code that we can call up to
do what you want.  I *know* there's no such "app picker" on Linux; as for the
Mac I can't say.

"Open With..." has to open a file picker.  Therefore, your proposal suffers from
the problems I point out.

>It is also completely untrue, as you'll know if you've ever chosen `Open 
>With...' in Windows Explorer, or double-clicked on a document with no creator 
>code in the Mac OS Finder. It's an application picker, not a file picker.

It is completely *true*, as you'll know if you ever stopped to realize that
these are parts of Windows Explorer and the Mac OS Finder.  The fact that there
in there doesn't mean Mozilla can get at it.

>That's not true either, because (a) it's an application picker, not a file 
>picker, and (b) the previous choice is selected by default.

In your imaginary world.

I also think you're imagining the fact that this scheme is better.  Every single
user scenario becomes more difficult (measured in terms of clicks and dialogs
encountered) and it has no way of providing features that users will demand
(e.g., Linux users want to type the name of their helper app programs, some
users want to be able to go back to the system default application after having
run a different application).

But it does convert the radio buttons to push buttons.  So it must be correct.

Still invalid, sorry.









Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → INVALID
Just my 0.02p.

I agree with Matthew's original points 1 (alert), 2 (text incorrect), and 3 
(radio buttons suck).

However, I would argue that it *is* better to have an 'always ask' checkbox 
than a 'remember this action' checkbox, since we're asking the computer to 
remember to ask us before opening these files.  Automatically running 
applications is bad, IMO.

The name of the associated application *should* also be shown on the dialog.  I 
like to know what application I'm opening the file with (especially if it's 
going to be lpr).  We do need an 'Open It!'-style button.

> It is completely *true*, as you'll know if you ever stopped to realize that
> these are parts of Windows Explorer and the Mac OS Finder.  The fact that
> there in there doesn't mean Mozilla can get at it.
> [...]
> In your imaginary world.

This is a bit harsh, isn't it?  I wouldn't expect everyone to have a deep 
understanding of shell internals.  As a matter of fact, you can get access to 
the 'Open With' dialog in Windows (OpenAs_RunDLL in shell32), but it's 
undocumented, so we probably don't want to use it.  I don't know about the Mac, 
sorry.

I think we have two very similar dialogs here.  One is presented when the file 
has an existing association, and the other when it does not.

How about the following two dialogs:

Handled by an existing application:
,-----------------------------------------------------------------------.
|:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
|-----------------------------------------------------------------------|
|   .   The file "showattachment.cgi" is of type foo/bar, and Mozilla   |
|  /!\  does not automatically handle this file type.                   |
|  """                                                                  |
|       This file type is currently handled by Application Name.        |
|                                                                       |
|       You can choose to open this file with Application Name, choose  |
|       another application or plug-in to open the file with, or you    |
|       can save it to disk.                                            |
|                                                                       |
|       [/] Always _ask before handling files of this type              |
|                                                                       |
|       (Open _With...) (_Save...) (View as _Text)   (Cancel) ((Open))  |
`-----------------------------------------------------------------------'

Windows:
|         [[Open]] [Open _With...] [_Save...] [View as _Text] [Cancel]  |
`-----------------------------------------------------------------------'

Not handled by an existing application - basically mpt's original proposal:
,-----------------------------------------------------------------------.
|:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
|-----------------------------------------------------------------------|
|   .   The file "showattachment.cgi" is of type foo/bar, and Mozilla   |
|  /!\  does not automatically handle this file type.                   |
|  """                                                                  |
|       You can choose an application or plug-in to open the file with, |
|       or you can save it to disk.                                     |
|                                                                       |
|       [/] Always _ask before handling files of this type              |
|                                                                       |
|               (_Save...) (View as _Text)   (Cancel) ((Open With...))  |
`-----------------------------------------------------------------------'

Windows:
|                 [[Open With...]] [_Save...] [View as _Text] [Cancel]  |
`-----------------------------------------------------------------------'

What exactly should we do when the user selects 'open with'?  Ideally, we 
present a dialog similar to the Windows 'Open With' dialog (as mpt suggested): 
a list of applications and a checkbox to allow the user to override the default 
application.

To me, the 'always ask' and 'default application' selections are independent 
choices.
mass-verification of Invalid bugs.

if you don't think the report is invalid, please check to see if it has already
been reported (it might be a duplicate instead). otherwise, make sure that there
are steps (a valid test case) that clearly display the issue as an unexpected
defect.

mail filter string for bugspam: SequoiadendronGiganteum
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: