395317 - Download dialog directions for changing preferences are no longer correct

Status: RESOLVED FIXED

(Firefox :: General, defect, P1)

Description

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

The toolkit unknown content type dialog refers to the "Content section of <platform specific pointer to preferences>" (see URL). There are three issues with that:

1) This dialog lives in toolkit, and those instructions are Firefox specific
2) Those instructions are no longer correct for Firefox, given the patch for bug 377784
3) Those instructions are a pain to maintain because we have to remember to update them when we change the preferences window.

I think we can fix all three issues by using a more generic string. Something like "In &brandShortName (preferences|options)", perhaps? Or maybe we can just get rid of this string altogether and assume that people looking to fix this will go to the preferences anyways?

Comment 1

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

Another option would be to move the Applications prefpane to toolkit.  But only if other applications want it, so cc:ing the Thunderbird folks.  Also cc:ing faaborg for his thoughts on UX.  My impression is that it's useful to tell people they can change this in preferences, since they might not otherwise know to look there (we do, but others are not like us), so we should still have a string.

Comment 2

[Mook (songbird dead account)]

Or possibly put the string in a .properties file, and just not show the text if JS fails to get it.  Hopefully in a chrome path that's app name/type agnostic (i.e. please don't put it in chrome://browser/ )

philor also suggested having a generic stub version, and let the app override (via chrome.manifest I presume).  I'm not quite sure what would go in a generic text, though...

Comment 3

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

(In reply to comment #1)
> Another option would be to move the Applications prefpane to toolkit.  But
> only if other applications want it, so cc:ing the Thunderbird folks.

I don't see how moving the code to Toolkit helps... we still need to describe application-specific ways of getting the prefpane to appear.

> My impression is that it's useful to tell people they can change this in
> preferences, since they might not otherwise know to look there (we do, but
> others are not like us), so we should still have a string.

I'm not convinced that users who care to change these kinds of settings (what to do with files of type X) are averse to or unfamiliar with pref dialogs. Even if that were true, I don't think telling them where to change the impacts of a decision before (or while) they're making it is all that useful; I think it's more likely that they'll want to change the action for a given type at some point in the future, where it's fairly likely that they won't remember the instructional string anyways.

Comment 4

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

Shouldn't the toolkit unknown content type dialog get replaced with the unified content handling dialog at some point? (http://wiki.mozilla.org/ContentHandling:User_Interface/Proposed_UI2)

Until then:

>I think we can fix all three issues by using a more generic string. Something
>like "In &brandShortName (preferences|options)", perhaps?

I would make the directions a little more descriptive: "using the Applications tab in &brandShortName's (preferences|options)" But as you point out, this text is specific to Firefox.

>I think it's
>more likely that they'll want to change the action for a given type at some
>point in the future, where it's fairly likely that they won't remember the
>instructional string anyways.

The message in the new content handling dialog only appeared if the user checked "remember my choice," and it served two purposes:
1) teach the user how to undo the action (as you point out they may not remember)
2) inform the user that it is possible to undo the action later

Comment 5

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

Attachment: patch v1: generic Toolkit message plus browser-specific override

(In reply to comment #2)
> philor also suggested having a generic stub version, and let the app override
> (via chrome.manifest I presume).  I'm not quite sure what would go in a 
> generic text, though...

Hmm, it turns out there's an existing mechanism for browser files to override generic files.  It's just a matter of putting the appropriate lines into the browser/locales/jar.mn file (which already has a couple of explicit overrides).


(In reply to comment #3)
> I don't think telling them where to change the impacts of a
> decision before (or while) they're making it is all that useful; I think it's
> more likely that they'll want to change the action for a given type at some
> point in the future, where it's fairly likely that they won't remember the
> instructional string anyways.

It's true that users may not remember the message, but there's a chance they will, especially if they see it a number of times before they decide to make a change, and that repetition prompts recall.

Even better would be to link the message to the prefpane, so users curious about what the message is describing can open the prefpane immediately and have the message reinforced by seeing the prefpane in action.  But that's another bug.


(In reply to comment #4)
> Shouldn't the toolkit unknown content type dialog get replaced with the 
> unified content handling dialog at some point?
> (http://wiki.mozilla.org/ContentHandling:User_Interface/Proposed_UI2)

Seems like it should.


> Until then:
> 
> >I think we can fix all three issues by using a more generic string. Something
> >like "In &brandShortName (preferences|options)", perhaps?
> 
> I would make the directions a little more descriptive: "using the Applications
> tab in &brandShortName's (preferences|options)" But as you point out, this 
> text is specific to Firefox.

Let's do both, with a more generic string in the toolkit version and a more specific string in the browser version that overrides it.

Here's a patch that implements this approach.

Comment 6

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

Attachment: patch v2: unrotted

Comment 7

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

Checking in browser/locales/jar.mn;
/cvsroot/mozilla/browser/locales/jar.mn,v  <--  jar.mn
new revision: 1.72; previous revision: 1.71
done
Checking in toolkit/locales/jar.mn;
/cvsroot/mozilla/toolkit/locales/jar.mn,v  <--  jar.mn
new revision: 1.41; previous revision: 1.40
done
Checking in toolkit/mozapps/downloads/content/unknownContentType.xul;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/unknownContentType.xul,v  <--  unknownContentType.xul
new revision: 1.23; previous revision: 1.22
done
RCS file: /cvsroot/mozilla/toolkit/locales/en-US/chrome/mozapps/downloads/settingsChange.dtd,v
done
Checking in toolkit/locales/en-US/chrome/mozapps/downloads/settingsChange.dtd;
/cvsroot/mozilla/toolkit/locales/en-US/chrome/mozapps/downloads/settingsChange.dtd,v  <--  settingsChange.dtd
initial revision: 1.1
done
Checking in toolkit/locales/en-US/chrome/mozapps/downloads/unknownContentType.dtd;
/cvsroot/mozilla/toolkit/locales/en-US/chrome/mozapps/downloads/unknownContentType.dtd,v  <--  unknownContentType.dtd
new revision: 1.8; previous revision: 1.7
done
RCS file: /cvsroot/mozilla/browser/locales/en-US/chrome/overrides/settingsChange.dtd,v
done
Checking in browser/locales/en-US/chrome/overrides/settingsChange.dtd;
/cvsroot/mozilla/browser/locales/en-US/chrome/overrides/settingsChange.dtd,v  <--  settingsChange.dtd
initial revision: 1.1
done

Comment 8

[Axel Hecht [:Pike]]

For reference, using overrides is the right thing to do here.