395138 - show types set to "always ask" in Applications prefpane

Status: RESOLVED FIXED

(Firefox :: File Handling, defect, P2)

Description

[Myk Melez [:myk] [@mykmelez]]

We should show types that Firefox is configured to "always ask" about in the  Applications prefpane in order to give users the chance to configure those types to do something else instead.

It's true that users can also reconfigure these types by trying to download some content of that type, but that's a roundabout way of providing this functionality, and it will be confusing to some users who go to the Applications prefpane expecting to see all the types they've previously downloaded.

Comment 1

[Alex Faaborg [:faaborg] (Firefox UX)]

We need to support undo.  If the user is used to changing their content handling preferences in this dialog, and they decide one day they want TIFF files and PNG files to always load in photoshop, they need to be able to find these items in the list.  Since we are favoring common types and applications at the top, so these entries don't get in the way.  Without this change, the user has to find the same type of file they want to change the behavior of on the Web, and then change the behavior using the content handling dialog itself, which is a really indirect way to change an application's preferences.

Comment 2

[Myk Melez [:myk] [@mykmelez]]

I'm inclined to agree with Alex.  From a user's perspective, I don't think there's a clear difference between "content types I've encountered" and "content types I've encountered that I told Firefox to always ask me about".  Users will sometimes open the prefpane to configure one of the latter types, and it will be confusing that they can't (and difficult to figure out how to work around that).

But mconnor might disagree.  Mike, any thoughts?

Comment 3

[Jesper Kristensen]

This sounds to me like "we should show every content type the user has ever encountered". This seems to me to be an awful lot of entries in the list. Does anyone have an idea of the magnitude of rows the list will then contain?

Comment 4

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #3)
> This sounds to me like "we should show every content type the user has ever
> encountered". This seems to me to be an awful lot of entries in the list. Does
> anyone have an idea of the magnitude of rows the list will then contain?

In my case, my years-old profile records 55 types I've ever encountered, of which 40 appear in the list, so showing all types would not make much difference.  But I have no idea how whether this is typical or exceptional.

Comment 5

[Myk Melez [:myk] [@mykmelez]]

Requesting wanted-1.9 for this Applications prefpane polish fix.

Comment 6

[Mike Connor [:mconnor]]

I'm ok with this, its worth trying at least, in lieu of Remove Action.  I'm not sure its the better way, and I've argued against this in the past in a slightly different form, but hey, I'm allowed to change my mind...

Comment 7

[Myk Melez [:myk] [@mykmelez]]

Attachment: patch v1: "always ask" for all types

Comment 8

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 282680 [details] [diff] [review]
patch v1: "always ask" for all types

>Index: browser/components/preferences/applications.js

>+    {
>       let menuItem = document.createElementNS(kXULNS, "menuitem");
>       menuItem.setAttribute("alwaysAsk", "true");
>+      let label;
...
>+    }

>+    if (handlerInfo.type == TYPE_MAYBE_FEED) {
>       menuItem = document.createElementNS(kXULNS, "menuitem");
>       menuItem.setAttribute("action", Ci.nsIHandlerInfo.handleInternally);
>       label = this._prefsBundle.getFormattedString("liveBookmarksInApp",

Leaving that block in makes "menuItem" and "label" go out of scope, so a strict warning is produced by the second block when you assign to them again. Re-declare menuItem and label with "let" in the second block, or remove the first block and use "var" to declare them.

Comment 9

[Myk Melez [:myk] [@mykmelez]]

Attachment: patch v2: addresses review comment; unrotted

(In reply to comment #8)
> Leaving that block in makes "menuItem" and "label" go out of scope, so a
> strict warning is produced by the second block when you assign to them again.
> Re-declare menuItem and label with "let" in the second block, or remove the
> first block and use "var" to declare them.

Good catch.  I now declare label with "let" in the second block, and the checkin for bug 395250 declares menuitem (renamed internalMenuItem) with "var".

Here's the patch that has that change and is unrotted (simple conflicts, no functionality issues).  This is the version of the patch I'll check in.

Comment 10

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 283439 [details] [diff] [review]
patch v2: addresses review comment; unrotted

Requesting approval to check in this patch for a wanted-firefox3 bug.  The patch itself is low risk, although the change in functionality may prove controversial.

But we need it in order to fix a regression in functionality caused by the fact that you can no longer "remove" a type from the list, and smart folks like mconnor and faaborg are ok with or supportive of this change, so I think it's worth making it, even at the risk that we'll back it out later if it proves more problematic than useful.

Comment 11

[Myk Melez [:myk] [@mykmelez]]

Checking in browser/components/preferences/applications.js;
/cvsroot/mozilla/browser/components/preferences/applications.js,v  <--  applications.js
new revision: 1.19; previous revision: 1.18
done
Checking in browser/locales/en-US/chrome/browser/preferences/preferences.properties;
/cvsroot/mozilla/browser/locales/en-US/chrome/browser/preferences/preferences.properties,v  <--  preferences.properties
new revision: 1.19; previous revision: 1.18
done

Comment 12

[u88484]

I have a very hard time getting the always ask to stick.  Like I click for windows media/audio playlist in which windows media player plugin dynamic is the application, set it to always ask and select another content type and it changes back to windows media player plugin dynamic.

I also have this problem with save file.

Comment 13

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #12)
> I have a very hard time getting the always ask to stick.  Like I click for
> windows media/audio playlist in which windows media player plugin dynamic is
> the application, set it to always ask and select another content type and it
> changes back to windows media player plugin dynamic.
> 
> I also have this problem with save file.

Thanks for the tip.  I have filed bug 398626 on these problems.