1736924 - Run a one-time migration for existing always-ask preferences for mimetypes stored in handlers.json to switch to "save to disk"

Status: RESOLVED FIXED

(Firefox :: File Handling, defect, P3)

Description

[:Gijs (he/him)]

When the download improvement pref is enabled, we default to saving files to disk.

That default won't override user preferences when those preferences are "always ask". In those cases, we should run a one-time migration so users get a consistent experience, and don't have to wonder why some files prompt and other files do not. This is particularly necessary because setting the default for a filetype to "always ask" isn't really a conscious act - it happens whenever users pick a non-default option in the "what do you want to do with this file" dialog, without ticking the "always do this" checkbox, or when users add custom file handlers (and, again, don't make those file handlers always open the file by ticking the checkbox). As a result, the presence of this saved preference isn't really usable as an indicator of user intent.

We should make sure to select the right default - this is usually save to disk, but not for PDFs (unless pdfjs is disabled) and other internally-viewable types (again, unless their relevant pref is turned off).

We should also make sure to only run this once, iff the improvements to downloads pref is enabled. This is tricky because we're likely to enable the pref in the 95 cycle on nightly, and in the 96 cycle elsewhere. As a result, it likely can't (solely) rely on the customary BrowserGlue.jsm's _migrateUI stuff incrementing.

Comment 1

[Mike Kaply [:mkaply]]

Enterprise policy can set these handlers. We should not do any migration if enterprise policy was used to set the handlers to a specific value.

Comment 2

[:Gijs (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #1)

Enterprise policy can set these handlers. We should not do any migration if enterprise policy was used to set the handlers to a specific value.

Do we have any way of determining if this was the case?

Comment 3

[Mike Kaply [:mkaply]]

Something like:

if (Services.policies.getActivePolicies().Handlers) {
// Don't migrate
}

should be enough.

Comment 4

[:Gijs (he/him)]

Mass moving affected flag for download improvements issues found on Nightly to 96 (nightly from later today / tomorrow), as the download improvements pref will be disabled for 95 beta.

Comment 5

[kpatenio]

Attachment: Bug 1736924 - create one-time migration for alwaysAsk mimetype prefs to saveToDisk if downloads improvements pref is enabled. r=gijs!

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2a82358537bd
create one-time migration for alwaysAsk mimetype prefs to saveToDisk if downloads improvements pref is enabled. r=Gijs

Comment 7

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/2a82358537bd

Comment 8

[mirh]

Sigh. I guess I'm the first power user complaining? (assuming you did some usability study definitively showing this was really an improvement, that is).
I get that there's a lot of people that *barely* can find the strength and courage to click "OK", but the "ask me first" dialog was exactly how I handled at the origin files that I knew were going to be temporary, from those that I actually wanted to save.
Archives being the most obvious and painful example of disposability.

I have seen bug 1710926, comment 6 then, but I'm still baffled.
"Unattended" download could always have started even without user approval.
And all things being equal, surely there must be more users annoyed because they have to manually delete a lot of files, rather than those using some stupid application "in which the file was opened didn’t provide a way of saving a separate copy"?

Comment 9

[:Gijs (he/him)]

(In reply to mirh from comment #8)

Sigh. I guess I'm the first power user complaining? (assuming you did some usability study definitively showing this was really an improvement, that is).
I get that there's a lot of people that *barely* can find the strength and courage to click "OK", but the "ask me first" dialog was exactly how I handled at the origin files that I knew were going to be temporary, from those that I actually wanted to save.
Archives being the most obvious and painful example of disposability.

You can still configure such archive files to either always prompt you, or always open directly with your (un)archiver tool of choice, using the controls in Firefox's settings (and you can add filetypes to those settings using the context menu in the downloads panel or library downloads view - x-ref the SUMO documentation.

At this point, I think all the issues raised in your comment are covered by the discussions in bug 1738574. Yes, we're confident in the trade-off in consequences for different usecases here. bug 1747343, bug 1746880, bug 1745624 (already fixed), and the strategies suggested in bug 1738916 comment 9, might make your life a bit easier, depending on exactly what you're doing. At this point, the bar for further changes is pretty high, as the behaviour changes have been live on nightly for over 2 months and are now riding the trains -- but if there's still something you think we overlooked, please file a new bug rather than trying to have this conversation on a closed and not directly related bug like this one.

Comment 10

[Tomáš Trnka]

What is the best way to prevent this migration from running (on FF98) or to undo its effects after it runs? I want most mimetypes set to "Always ask" (and I can live with new unknown mimetypes defaulting to Download until bug of 1747343 gets fixed, it's fairly unlikely I'll encounter completely new mimetypes any often). Due to this migration, I have ended up with everything set to Download, which is fairly useless for me (I have never used that for any mimetype).

Restoring my profile from backup apparently is not a solution as this migration then goes and resets everything again. The list in Preferences doesn't seem to support changing the desired action for multiple items at once or some fast non-clicky way of switching items to Always ask (clicking through all the 50+ entries there, times three machines/five profiles, doesn't sound fun).

Right now, the only solution I found is running a search&replace on handlers.json, which feels quite hacky (I'm afraid something might break). Making handlers.json immutable doesn't seem to work well either.

Is restoring only handlers.json from a backup (without touching the rest of the profile) a safe option?

Comment 11

[Karel Koubek]

Hello,
I have been a long long time devoted Firefox user, but recently I have been experiencing some really wrong UX decisions affecting power users, who IMHO are the core of the Firefox user and fan base and they shouldn't be neglected this way.

First, it was the reduction of useful right-click options (View Image Info to name few, luckily people earned it back after some riots), then the always popping up download manager (about:config still saves the day, but for how long?) and now this mindless decision to switch "always ask" to "save file" without user content? Not speaking about the "always ask" killed forever, which was the most ergonomically smooth behavior for my use of Firefox.

How could have been this substantial change stealthily accepted without a proper front-end migration wizard, assistant, or at least informative pop-up? Who is doing these decisions, that alienate the long-term user base?

I have about 30 file types in the list and now I have to go one by one, to set them to the default app, great!

I'm not the only one disappointed by this change, my parents don't like it, just today my accountant told me, that somehow the browser doesn't open the files by the default system app like it used to.

Does the Firefox team do proper A/B user testing? It is so sad to see my beloved browser getting illogical and user unfriendly in some key areas :(

What can we do about it?

Comment 12

[:Gijs (he/him)]

(In reply to Tomáš Trnka from comment #10)

Is restoring only handlers.json from a backup (without touching the rest of the profile) a safe option?

Yes, but the migration will re-run, as whether it has run is tracked in the same handlers.json file. Add the "isDownloadsImprovementsAlreadyMigrated": true property into the toplevel object to prevent that from happening.

(In reply to Karel Koubek from comment #11)

How could have been this substantial change stealthily accepted without a proper front-end migration wizard, assistant, or at least informative pop-up?

What is substantial for one person isn't for another. We made a deliberate decision that this wasn't likely to be something to bother most people with.

We didn't change anything for filetypes set to "open with [app]" by default (as opposed to "always ask"); if you or your accountant is seeing something else, please file a separate bug for that. We cannot solve every individual's issue in the same bug, it becomes completely unmanageable both for the individuals concerned and for the engineers trying to write patches.

Comment 13

[Karel Koubek]

(In reply to :Gijs (he/him) from comment #12)

What is substantial for one person isn't for another. We made a deliberate decision that this wasn't likely to be something to bother most people with.

We didn't change anything for filetypes set to "open with [app]" by default (as opposed to "always ask"); if you or your accountant is seeing something else, please file a separate bug for that. We cannot solve every individual's issue in the same bug, it becomes completely unmanageable both for the individuals concerned and for the engineers trying to write patches.

Thanks for the reply and sorry for my overly emotional reply. I wasn't correct in my wording, my relatives and accountant had most of the file types set to "Always ask" before, because that is how the profiles were set up in the dark ages of internet and early ages of Firefox. So now I need to instruct them to go line by line, and switch to "Always ask" as it was before, correct? And this must be done on all PCs, or is this setting synchronized via Firefox account?

Thanks for your reply.

Comment 14

[:Gijs (he/him)]

(In reply to Karel Koubek from comment #13)

(In reply to :Gijs (he/him) from comment #12)

What is substantial for one person isn't for another. We made a deliberate decision that this wasn't likely to be something to bother most people with.

We didn't change anything for filetypes set to "open with [app]" by default (as opposed to "always ask"); if you or your accountant is seeing something else, please file a separate bug for that. We cannot solve every individual's issue in the same bug, it becomes completely unmanageable both for the individuals concerned and for the engineers trying to write patches.

Thanks for the reply and sorry for my overly emotional reply. I wasn't correct in my wording, my relatives and accountant had most of the file types set to "Always ask" before, because that is how the profiles were set up in the dark ages of internet and early ages of Firefox. So now I need to instruct them to go line by line, and switch to "Always ask" as it was before, correct?

If that's what they want, yes. I'm still curious why though - the downloads panel appears when the download starts, so if they want to open the file they can just click the entry in there - it's just as many steps/clicks as before. (You can also click the entry before the download completes; the file will open when the download finishes.)

And this must be done on all PCs, or is this setting synchronized via Firefox account?

Unfortunately these settings are not sync'd via Firefox accounts.

Comment 15

[Karel Koubek]

(In reply to :Gijs (he/him) from comment #14)

If that's what they want, yes. I'm still curious why though - the downloads panel appears when the download starts, so if they want to open the file they can just click the entry in there - it's just as many steps/clicks as before. (You can also click the entry before the download completes; the file will open when the download finishes.)

Thanks for your further reply :Gijs, that is not completely correct, I just tested both scenarios. There is one extra dialog, which the user must endure now, when he/she wants to just open the file on screen - the file explorer asks me first, where to save the file (I have the option checked 'Always ask you where to save the file', it is a must for a workflow when the files should be saved in any meaningful way to your folder structure).

What the "Always ask" option does, that I can skip this download selection process, when just pure opening of the file is needed. It is a huge time saver and the new behavior doesn't work - the user must save the file first somewhere to the disc, then open it, just to see the file and then discard it.

Do you see the problem in this type of use? I think most people that use their browser for work will have the option 'Always ask you where to save the file' turned ON.

Comment 16

[:Gijs (he/him)]

Thanks for clarifying, that makes more sense to me. bug 1747343 is probably what you're interested in, then. In the meantime, as a workaround, which I acknowledge is exactly that and doesn't fully address what you're describing perhaps for some filetypes it may be easier for you if you set them to always open in whatever app you'd view them in (which you can do from the context menu in the downloads panel, or from the Firefox settings page if an entry for that type is already there) - you can still decide to save a copy from that viewer in most cases, or, for files that you know beforehand you just want to save and not open, use "save link as..." from the context menu on the link to the file.