173465 - Add UI for mail/news "network.protocol-handler.external..." preferences

Status: RESOLVED FIXED

(SeaMonkey :: Preferences, enhancement)

Description

[Scott]

Why not allow users the option of setting settings such as
"network.protocol-handler.external.mailto" in the preferences section.  This
would make the browser more customizable to its users.

Comment 1

[Mats Palmgren (inactive)]

*** This bug has been marked as a duplicate of 17199 ***

Comment 2

[sairuh (rarely reading bugmail)]

v

Comment 3

[benc]

REOPEN:
This should have a more accurate dupe, or be a separate bug.

Comment 4

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 5

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.

Comment 6

[benc]

Although Seamonkey users tend to be independent types, I think this still has merit. Some people might be using Seamonkey in places that are Outlook shops, and there is a lot of non-mailer functionality integrated into Outlook that you just don't get in Mailnews.

Comment 7

[RickieES aka Ricardo Palomares]

Relabeling as enhancement, and changing hw/os impact.

Comment 8

[Tony Mechelynck [:tonymec]]

- This enhancement is obviously not (yet) present => Confirming.
- I can imagine some people would use it if present. I wouldn't, but at least its presence wouldn't hamper me in any way.
- SeaMonkey (trunk) prefs are in the process of being ported to a different backend. The top mailnews page is already ported, but none of its subpages. I'm not sure in which prefs page (mailnews? browser? one of their subpages, and which?) this enhancement (if enabled) would belong. Karsten? Mark? Neil?
- Not sure whether to retarget to "Future" or leave it as "---". Priority should probably be set low, but how low?

Comment 9

[Karsten Düsterloh]

> The top mailnews page is already ported, but none of its subpages. I'm
> not sure in which prefs page (mailnews? browser? one of their subpages, and
> which?) this enhancement (if enabled) would belong.

I don't think that it actually would belong onto a MailNews page at all, since it's about *not* using MailNews from the browser (mainly)...

Comment 10

[Serge Gautherie (:sgautherie)]

(Filter "spam" on 'prefs-nobody-20080612'.)

Comment 12

[Jens Hatlak (:InvisibleSmiley)]

I think we should at least make this pref appear in about:config by default (by giving it a default value of "false"). Beyond that I support making it available via Preferences UI because users keep asking about this functionality, which already exists in our product but which is hard to find.

Unlike Karsten I think "Mail & Newsgroups" (top pane, probably) would be a good place to have it, because naturally that's where people would look for it first. We could put it as the first item under "General settings" and call it something like "Use SeaMonkey for mailto: links", default checked (making it a reversed/inverted UI/pref relationship).

Alternatively, there's lots of free space on the Advanced panel, but personally I'm opposed to putting things under this category (in fact I think having it at all was a bad thing to do in the first place, but that's beyond the scope here).

Comment 13

[rsx11m]

(In reply to Jens Hatlak (:InvisibleSmiley) from comment #12)
> I think we should at least make this pref appear in about:config by default
> (by giving it a default value of "false"). Beyond that I support making it
> available via Preferences UI because users keep asking about this
> functionality, which already exists in our product but which is hard to find.

I have a patch pending review for this in bug 995706 as result of the recent Yahoo fallout, so this may be taken care of.

> Unlike Karsten I think "Mail & Newsgroups" (top pane, probably) would be a
> good place to have it, because naturally that's where people would look for
> it first. We could put it as the first item under "General settings" and
> call it something like "Use SeaMonkey for mailto: links", default checked
> (making it a reversed/inverted UI/pref relationship).

We actually have the UI for setting it the default application there, so I like having checkboxes for "Use SeaMonkey for {mail,news} links" around that location too (the problem being that news actually has three protocols which need to be combined into a single checkbox to avoid confusing the user, or we are just combining all four prefs to a single checkbox).

> Alternatively, there's lots of free space on the Advanced panel, but
> personally I'm opposed to putting things under this category

Alternatively(2), this would also fit logically into the Browser's "Link Behavior" pane, first group:

--- Link open behavior ---
  ...
When opening mail/news links:
  (*) Use SeaMonkey's Mail & Newsgroups windows
  ( ) Use an external site or application

I'll give either a try.

Comment 14

[rsx11m]

Attachment: Version A: Mail & News main prefpane

This adds a description and two checkboxes for the mail and news protcols, based on the inverted prefs as suggested. Note that the news box covers the snews and nttp protocols as well (i.e., it's set from .news but toggling the box will also set the .snews and .nntp protocols to external, unless they are locked).

This patch goes on top of bug 995706 attachment 8407963 [details] [diff] [review].

Comment 15

[rsx11m]

Attachment: Version A: Screenshot

Fits right underneath the settings for the default applications and seems to fit there logically quite well.

Comment 16

[rsx11m]

Attachment: Version B: Link Behavior prefpane

This version puts another radiogroup into the Browser's Link Behavior pane, which is an alternative location suggested in my comment #13.

The logic here is a bit more complicated than in Version A. It's in fact a tri-state logic (all protocols "false", all protocols "true", or mixed, the latter hidden from the user) which is initialized by looping over all pref values when picking the initial state. When clicking on either radiobutton, all prefs are set to the respective value. Preferences which are locked aren't considered.

Again, to be applied on top of bug 995706 attachment 8407963 [details] [diff] [review].

Comment 17

[rsx11m]

Attachment: Version B: Screenshot

Looks visually consistent but extends the pane quite a bit vertically. Consequently, this version triggers the bug 868495 pane extension on Windows 7 Aero.

Comment 18

[rsx11m]

IanN: I'll add the updates to the Help content once either of the patches has received a ui-r+.

Comment 19

[Tristan Miller]

(In reply to rsx11m from comment #17)
> Created attachment 8409405 [details]
> Version B: Screenshot

What's the purpose of including the words "in a window"?  Where else would the user be following a mail/news link?  Is there an important distinction here which this phrase is disambiguating, or is this text just redundant?

Also, should we be using the word "clicking" to describe following a link?  Not all users use a mouse, and another label in this dialog talks about "open"ing links rather than clicking them.  Is there a Mozilla language style guide for this?

Comment 20

[rsx11m]

I'm flexible here. Neil?

Comment 21

[rsx11m]

Comment on attachment 8409404 [details] [diff] [review]
Version B: Link Behavior prefpane

(In reply to Tristan Miller from comment #19)
> What's the purpose of including the words "in a window"?

Interestingly, it can be both a browser or a mail document - when you open a link in content and the preference is set, then the external mail handler is invoked. On the other hand, right-clicking on a link and selecting "Compose Mail To" (available in a Mail/News window only) opens SeaMonkey's internal composition window. Thus, "document" is probably the better choice here.

> Also, should we be using the word "clicking" to describe following a link?

Good point, "opening" is certainly more general.

>+<!ENTITY mailNewsDescription.label "When clicking on a mail/news link in a window:">

So, maybe "When opening a mail/news link in a document:" would be better?

Comment 22

[Tristan Miller]

I don't see how the distinction between browser windows and mails is relevant to my question.  I was asking why any sort of qualification whatsoever is necessary in the label -- that is, why not just have it read "When opening a mail/news link:"?

Comment 23

[rsx11m]

As compared to clicking on a link-like e-mail address in the header UI, for example? As said, I'm fine with the shortening the description, let's see what Neil and IanN think is the best solution.

Comment 24

[Ian Neal]

Comment on attachment 8409402 [details] [diff] [review]
Version A: Mail & News main prefpane

>+++ b/suite/mailnews/prefs/pref-mailnews.js

>+function onNewsChange(value)
Nit: Use "aValue" rather than "value".

>+++ b/suite/mailnews/prefs/pref-mailnews.xul

>+      <preference id="network.protocol-handler.external.news"
>+                  name="network.protocol-handler.external.news"
>+                  onchange="onNewsChange(this.value)"
Nit: Add ; to the end of the function call.
>+                  inverted="true" type="bool"/>
r=me with those addressed.
I prefer this option over option B, mainly as there is more control mailto vs news but there is also the argument that this to do with whether mailnews handles certain protocols rather than what the browser does with certain protocols.

Comment 25

[Ian Neal]

Comment on attachment 8409404 [details] [diff] [review]
Version B: Link Behavior prefpane

I prefer the greater control in Option A, so r-

Comment 26

[rsx11m]

Attachment: Version A: Help content added

Updated patch, attachment 8409402 [details] [diff] [review] with comment #24 addressed.

As promised, this also adds an item to the Help content for this prefpane, hence re-requesting review for that portion. I've noticed that I'm contradicting my own comment #21 here a bit (which was on Version B, but anyway) by using explicitly "browser" in the label. Since we are in the Mail & News context with this pane, that should be a good idea to clarify that this is the main use case for switching these checkboxes. The Help content states more explicitly that links from both browser and mail/news content are influenced.

Comment 27

[Ian Neal]

Comment on attachment 8413452 [details] [diff] [review]
Version A: Help content added

>+++ b/suite/locales/en-US/chrome/common/help/mailnews_preferences.xhtml
>@@ -87,16 +87,30 @@
>     application for Windows and from within other applications such as Microsoft
>     Word.
> 
>     <p><strong>Note</strong>: Setting &brandShortName; as the default
>       mail, news or feeds application may remove the connection that other
>       applications had with these tasks. Refer to the documentation of the
>       respective applications in order to find how to restore the defaults.</p>
>   </li>
>+  <li><strong>Use &brandShortName; Mail &amp; News when opening browser links
>+    for</strong>: By default, any links to email addresses or newsgroups opened
>+    from browser pages or other messages are handled by &brandShortName; itself.
>+    Uncheck the Mail and/or News boxes if you instead want an external
>+    application to handle such links. In this case, a dialog will open to
>+    select the application to be used.
I think there are commas missing from around "instead", also potentially this word should either be before the "if" or at then end of the sentence.

>+    <!-- remove the following warning once bug 198547 is fixed -->
>+    <p><strong>Note</strong>: Don&apos;t uncheck either of these boxes and then
>+      select &brandShortName; in the dialog unless it is also registered as the
>+      system&apos;s default mail or news application, respectively. Doing so
>+      may cause &brandShortName; to continuously prompt for the program to use
>+      when opening a link.</p>
"respectively" seems wrong, I know what you are trying to say though. Maybe "...also registered as the system&apos;s respective default mail or news application."? Not sure that is any better though.

r=me

Comment 28

[rsx11m]

Attachment: Version A: Mail & News main prefpane (v3)

(In reply to Ian Neal from comment #27)
> I think there are commas missing from around "instead", also potentially
> this word should either be before the "if" or at then end of the sentence.

I've opted for moving it at the end of that sentence, this seems to provide a better flow and makes it unambiguous what the "instead" refers to.

> "respectively" seems wrong, I know what you are trying to say though. Maybe
> "...also registered as the system's respective default mail or news
> application."? Not sure that is any better though.

That was my alternative phrasing as well, thus I'm going with that one given that you prefer it.

No other changes.

Comment 29

[[e-mail]]

Comment on attachment 8420714 [details] [diff] [review]
Version A: Mail & News main prefpane (v3)

Sorry to take so long to get around to reviewing this.

onchange is intended to allow the UI to update in response to changes in references. It's a sort of onsyncfrompreference on steroids, for when you need to update more than the value of a single UI element.

What you want here is to update a preference in response to a change in the UI. onsynctopreference might work here, but oncommand would probably be easier.

Comment 30

[rsx11m]

Attachment: Version A: Mail & News main prefpane (v4)

Ok, I'm going with the oncommand version; moving the event from the preference to the checkbox is rather straight-forward and doesn't require any changes to the JavaScript part (I'm just passing its "checked" status rather than the underlying pref's "value" - remains inverted in either case, thus no need to flip anything).

Comment 31

[rsx11m]

Attachment: Version A: Mail & News main prefpane (v5)

On a second thought, I'm changing "aValue" to "aChecked" as the parameter name for onNewsChange(), thus to better represent what's passed (and the value of the "checked" attribute is actually the inverse of the preference value, so this considers that a bit better as well).

Comment 32

[rsx11m]

Thanks Neil, push for comm-central please.

Comment 33

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/comm-central/rev/f66dffcd4617