Closed
Bug 136619
Opened 23 years ago
Closed 23 years ago
Redesign the unknown file type alert
Categories
(Core Graveyard :: File Handling, enhancement)
Core Graveyard
File Handling
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
Reporter | ||
Comment 1•23 years ago
|
||
Comment 2•23 years ago
|
||
> 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
Comment 3•23 years ago
|
||
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
Comment 5•23 years ago
|
||
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.
Reporter | ||
Comment 6•23 years ago
|
||
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 → ---
Reporter | ||
Comment 7•23 years ago
|
||
Reporter | ||
Comment 8•23 years ago
|
||
>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 ago → 23 years ago
Resolution: --- → INVALID
Comment 10•23 years ago
|
||
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.
Comment 11•22 years ago
|
||
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
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•