1306338 - [meta] Remove ability to choose a handler application that is not the system default

Status: RESOLVED WONTFIX

(Firefox :: File Handling, task, P3)

Description

[:Paolo Amadini]

When a page is loaded and the browser does not know how to handle its content type internally, we currently display a handler choice dialog that allows the user to choose an application to open the file with. This is normally the system default application associated to the content type.

The user has the option of choosing another application from a list provided by the operating system, or manually select a different executable in the system to be added to the list of possible handlers for the content type. The path to this new application is then remembered for the next time.

This bug is about removing the ability to choose a different application that is not the system default, including both custom applications and applications suggested by the operating system.

On the assumption that the right application has to be configured in the operating system, the ability to choose a custom executable should be removed both for file type handlers and for protocol handlers like "mailto:".

If there is no operating system default for the file type, we can show an operating system dialog at the time the file is launched, like we currently do. If we can't delegate to the operating system, like it happens for protocols, then we simply don't allow the protocol click to proceed or the downloaded file to be opened. We can still show downloaded files in the file manager, though.

These changes include the front-end preferences, and we should also keep in mind that this affects the choices offered on the internal feed viewer provided by "about:feeds".

We have to figure out what to do when the content type provided by the server is wrong or is ambiguous, and the file can be opened in multiple applications. We need to define how users can recover from the incorrect content type, and open the file with the right application.

At present, the above changes are not entirely covered in a user experience specification, so this likely needs more discussion. We can however already proceed to instrument some of the user flows related to this experience.

Comment 1

[Ben Tian (inactive)]

Paolo, some questions and clarification below.

(In reply to :Paolo Amadini from comment #0)
> the ability to choose a custom executable should be
> removed both for file type handlers and for protocol handlers like "mailto:".

Only removed for file type handlers per UX spec [1]. Ability to choose custom executable for protocol handler is still kept.
[1] https://mozilla.invisionapp.com/share/4Y6ZZH1E8#/screens/162255371 
 
> We have to figure out what to do when the content type provided by the
> server is wrong or is ambiguous, and the file can be opened in multiple
> applications. We need to define how users can recover from the incorrect
> content type, and open the file with the right application.

Can current Firefox handle these problems? If yes we can adopt existing approach for sure; if not we prefer to focus on dialog removal first and tackle these problems afterward.

Comment 2

[:Paolo Amadini]

(In reply to Ben Tian [:btian] from comment #1)
> Only removed for file type handlers per UX spec [1]. Ability to choose
> custom executable for protocol handler is still kept.
> [1] https://mozilla.invisionapp.com/share/4Y6ZZH1E8#/screens/162255371 

Ah, I was discussing this part of the specification with Gijs and we did find odd that the reasoning for removing the ability to choose a custom executable to handle a content type would not apply in the same way to choosing a custom executable for protocol handlers. Can someone from UX chime in and clarify the reasoning?

Are we trying to work around limitations of some operating systems? At least on recent Windows versions, if an application can handle a protocol type it can register itself so you get the application in the list to choose from.

Do our users actually use this feature at all? Maybe we could have a telemetry probe to find out.

> > We have to figure out what to do when the content type provided by the
> > server is wrong or is ambiguous, and the file can be opened in multiple
> > applications. We need to define how users can recover from the incorrect
> > content type, and open the file with the right application.
> 
> Can current Firefox handle these problems? If yes we can adopt existing
> approach for sure; if not we prefer to focus on dialog removal first and
> tackle these problems afterward.

Currently Firefox solves this problem by asking the user which application to use every time, if the user so chooses, from a list of possible registered handler applications. If the content type is wrong the user has to locate the executable of the correct application, which is sub-optimal and I guess isn't used unless it's strictly necessary.

Comment 3

[Ben Tian (inactive)]

(In reply to :Paolo Amadini from comment #2)
> > Only removed for file type handlers per UX spec [1]. Ability to choose
> > custom executable for protocol handler is still kept.
> > [1] https://mozilla.invisionapp.com/share/4Y6ZZH1E8#/screens/162255371 
> 
> Ah, I was discussing this part of the specification with Gijs and we did
> find odd that the reasoning for removing the ability to choose a custom
> executable to handle a content type would not apply in the same way to
> choosing a custom executable for protocol handlers. Can someone from UX
> chime in and clarify the reasoning?
> 
> Are we trying to work around limitations of some operating systems? At least
> on recent Windows versions, if an application can handle a protocol type it
> can register itself so you get the application in the list to choose from.
> 
> Do our users actually use this feature at all? Maybe we could have a
> telemetry probe to find out.

ni? UX designer Bryant to help clarify.

Comment 4

[Ben Tian (inactive)]

(In reply to :Paolo Amadini from comment #2)
> > > We have to figure out what to do when the content type provided by the
> > > server is wrong or is ambiguous, and the file can be opened in multiple
> > > applications. We need to define how users can recover from the incorrect
> > > content type, and open the file with the right application.
>
> Currently Firefox solves this problem by asking the user which application
> to use every time, if the user so chooses, from a list of possible
> registered handler applications. If the content type is wrong the user has
> to locate the executable of the correct application, which is sub-optimal
> and I guess isn't used unless it's strictly necessary.

I think the sub-optimal approach suffices to handle wrong content type. Default application would fail to open the file with wrong content type at first. The user can then locate the downloaded file on disk and open with correct application afterward. Do you have concern on this approach?

Comment 5

[:Paolo Amadini]

If I understand the proposal correctly, for these cases we won't support the ability to open the file automatically, because doing that would choose the wrong application. If the content type was set to open automatically, the recovery mode is for the user to close the incorrect application that was launched, then locate the saved file on disk with the correct application.

It's difficult to say whether users will understand this recovery mode without some testing.

Comment 6

[Bryant Mao [:bryantmao]]

(In reply to :Paolo Amadini from comment #2)
> (In reply to Ben Tian [:btian] from comment #1)
> > Only removed for file type handlers per UX spec [1]. Ability to choose
> > custom executable for protocol handler is still kept.
> > [1] https://mozilla.invisionapp.com/share/4Y6ZZH1E8#/screens/162255371 
> 
> Ah, I was discussing this part of the specification with Gijs and we did
> find odd that the reasoning for removing the ability to choose a custom
> executable to handle a content type would not apply in the same way to
> choosing a custom executable for protocol handlers. Can someone from UX
> chime in and clarify the reasoning?
> 
That's a very good question. In the new design, we removed the ability to choose a custom executable from the OS to handle a file simply because we think a user can easily do the selection task after they download the file to their disk. 

On the other hand, consider most of the protocols can not be downloaded, the user will have no chance to select a preferred executable to handle the protocol from their disk. Even if some of the protocols can be downloaded, it would be very unnatural for a user to save a protocol first then choose an executable to handle it afterward.

As we understand more about the behaviors of file and protocol, we think it's better to consider them as two different entities with their own definition and operation instead of applying the same rule. This also echoes to the reason behind the Bug 1306343, which we try to split the original application handler to file and protocol handler along with their own explanation in the Preferences in order to form a clearer mental model with the user.

Comment 7

[Bryant Mao [:bryantmao]]

(In reply to :Paolo Amadini from comment #5)
> If I understand the proposal correctly, for these cases we won't support the
> ability to open the file automatically, because doing that would choose the
> wrong application. If the content type was set to open automatically, the
> recovery mode is for the user to close the incorrect application that was
> launched, then locate the saved file on disk with the correct application.
> 
Agree, we do considering to not provide the ability of "Always open" for that kind of problematic files, but leave the decision to the user after they downloaded the files. But I wonder how can we recognize these problematic files once they start downloading? 

I am not sure if I understand well about the "Recovery mode" here. Paolo, can you elaborate more on that?

Comment 8

[:Paolo Amadini]

(In reply to Bryant Mao [:bryantmao] from comment #7)
> Agree, we do considering to not provide the ability of "Always open" for
> that kind of problematic files, but leave the decision to the user after
> they downloaded the files. But I wonder how can we recognize these
> problematic files once they start downloading? 
> 
> I am not sure if I understand well about the "Recovery mode" here. Paolo,
> can you elaborate more on that?

Since we cannot really recognize these problematic files without user input, we will necessarily incur in situations where we end up using the wrong application. This user input is currently provided by the handler choice dialog, and if the first attempt doesn't work, to recover from this situation a user can try the download again and make a different choice in this dialog. With the changes we are making, users will need to use a different process to recover, that involves the system file manager. Some users will be able to figure out how the new process works, more or less easily. Other users might need some help to understand the new procedure.

Comment 9

[Bryant Mao [:bryantmao]]

(In reply to :Paolo Amadini from comment #8)
> (In reply to Bryant Mao [:bryantmao] from comment #7)
> > Agree, we do considering to not provide the ability of "Always open" for
> > that kind of problematic files, but leave the decision to the user after
> > they downloaded the files. But I wonder how can we recognize these
> > problematic files once they start downloading? 
> > 
> > I am not sure if I understand well about the "Recovery mode" here. Paolo,
> > can you elaborate more on that?
> 
> Since we cannot really recognize these problematic files without user input,
> we will necessarily incur in situations where we end up using the wrong
> application.

If I understand correctly, what you mean is that we will know the problematic file indirectly by receiving a "fail to open" message from the OS?

> This user input is currently provided by the handler choice
> dialog, and if the first attempt doesn't work, to recover from this
> situation a user can try the download again and make a different choice in
> this dialog. With the changes we are making, users will need to use a
> different process to recover, that involves the system file manager. Some
> users will be able to figure out how the new process works, more or less
> easily. Other users might need some help to understand the new procedure.

I think the original recovery mode didn't solve the problem. 

If we fail to open the problematic file (say, a mp3 file wear a .pdf mask), a user will have to guess the correct application blindly in both situations. And since there is no way for us to identify the right file type directly, I assume we can only choose a path which is less tortuous.

Path1: With the dialogue (Current design) 
A user will repeat the following steps until they discover a right application to open the problematic file:

1. Click the download link 
2. Choose a preferred application to open the file on the dialogue (drop down> application list)
3. Wait for the file to be downloaded and open with the preferred application
4. Wait for the application to launch
5. Read through the error message

Path2: Without the dialogue (New design)
A user will have to repeat the following steps until they discover a right application to open the problematic file:

1. Locate the download file 
2. Right click the file
3. Choose a preferred application to open the file in the context menu (open with>application list)
4. Wait for the application to launch
5. Read through the error message

To me, neither path is perfect. But given that, a user on path one will have to wait for the file to be downloaded before another try, I will prefer the second path, which the user can make more attempts in relatively short time. And I think to choose an alternative application to open a file shouldn't be an unfamiliar task for most of the users.

Comment 10

[:Paolo Amadini]

(In reply to Bryant Mao [:bryantmao] from comment #9)
> (In reply to :Paolo Amadini from comment #8)
> > Since we cannot really recognize these problematic files without user input,
> > we will necessarily incur in situations where we end up using the wrong
> > application.
> 
> If I understand correctly, what you mean is that we will know the
> problematic file indirectly by receiving a "fail to open" message from the
> OS?

Yes, likely an error message in the operating system, displayed the application that tried to open the file.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The meta keyword is there, the bug doesn't depend on other bugs and there is no activity for 12 months.
:Paolo, maybe it's time to close this bug?

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The meta keyword is there, the bug doesn't depend on other bugs and there is no activity for 12 months.
:Gijs, maybe it's time to close this bug?

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

The meta keyword is there, the bug doesn't depend on other bugs and there is no activity for 12 months.
:Gijs, maybe it's time to close this bug?

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

The meta keyword is there, the bug doesn't depend on other bugs and there is no activity for 12 months.
:Gijs, maybe it's time to close this bug?

Comment 15

[:Gijs (he/him)]

I don't think we have any intentions to remove this in the short term.