Open Bug 708959 Opened 13 years ago Updated 2 years ago

Need User Interface for Selecting Applications for Non-HTTP URIs and for Various Attachments

Categories

(Thunderbird :: Preferences, enhancement)

x86
Windows XP
enhancement

Tracking

(Not tracked)

REOPENED

People

(Reporter: david, Unassigned)

References

()

Details

Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0

When I selected an FTP URI from a Thunderbird message, I got the page
displayed in Internet Explorer even though SeaMonkey is my default
browser.  An example of an FTP URI is
<ftp://ftp.rfc-editor.org/in-notes/rfc3986.txt>.  Selecting this link
from another Web page in SeaMonkey displayed the page for RFC 3986 in
SeaMonkey.  Selecting this link from a message in Thunderbird displayed
the page for RFC 3986 in IE.  

The solution was to set the preference variable network.protocol-handler.warn-external.ftp to True.  Then, on the next time I selected an FTP URI in a Thunderbird message, I got a popup dialogue allowing me to select SeaMonkey with a checkbox to make this selection permanent.  

This solution is definitely not user-oriented, and it is specific to FTP and not any other protocol.  A more general, user-oriented solution is requested, possibly via the Options window.
That just means your default ftp handler is IE. You'll have to change that somewhere (outside) thunderbird. Perhaps resetting the default browser can fix it, or then in the os preferences somewhere.
Summary: Need User Interface for Selecting Applications for URIs that are Not HTML → Need User Interface for Selecting Applications for non-http urls
I never set IE as my default FTP handler.  For years, I have been accessing FTP documents -- especially RFCs and Usenet management archives -- via Netscape, Mozilla Suite, and SeaMonkey and never by IE.  This worked under Windows 95, Windows 98, and Windows XP without even setting a default FTP handler.  

Only recently I tried to access an FTP document (again an RFC) from a FTP URI link in Thunderbird.  That is when I discovered this problem.  When composing this bug report, I was going to address only FTP URIs.  Except for HTTP, HTP, HTTPS, and HTPs, however, I realized that other URI protocols might also be affected.  Thus, I generalized this bug report.  

The problem was that Thunderbird sent the URI to another application and not in a Thunderbird window.  That is a correct response.  However, Thunderbird chose the wrong application.  Note that opening a local HTML file on my hard-drive has been using SeaMonkey, not IE.  Thus, SeaMonkey was already my default browser.  the same is true when selecting a link on a non-Mozilla application (e.g., for help).
(In reply to David E. Ross from comment #2)
> I never set IE as my default FTP handler.  For years, I have been accessing
> FTP documents -- especially RFCs and Usenet management archives -- via
> Netscape, Mozilla Suite, and SeaMonkey and never by IE.  This worked under
> Windows 95, Windows 98, and Windows XP without even setting a default FTP
> handler.  

but those all handled it themselves internally, no?

> The problem was that Thunderbird sent the URI to another application and not
> in a Thunderbird window.  That is a correct response.  However, Thunderbird
> chose the wrong application.  Note that opening a local HTML file on my
> hard-drive has been using SeaMonkey, not IE.  Thus, SeaMonkey was already my
> default browser.  the same is true when selecting a link on a non-Mozilla
> application (e.g., for help).

handling .html files locally is not the same as handlig http:// , ftp:// etc. on the OS level.

If you go to thunderbird options | attachments and type in ftp:// , does it say anything?
In Thunderbird, it now has FTP handled by SeaMonkey.  That is a result of my setting network.protocol-handler.warn-external.ftp to True, then selecting a link with an FTP URI, and then indicating in the popup dialogue that I want to use SeaMonkey.  

There are two problems with the above.  

1.  Where is this documented FOR END-USERS?  I had to pose my problem in the mozilla.support.thunderbird newsgroup, where it took some discussion before the above solution was suggested.  

2.  This is definitely not a USER-ORIENTED procedure.  Merely going to [Tools > Options > Attachments], a user is not given the capability to add to the list.  Instead, the user must instead go through the procedure I described above to get a new entry added to the list.   (This RFE could be implemented by creating the capability to add to the list.)
But you wouldn' have had to do any of that if your OS settings were set to what you want... or?
What Windows XP settings?
Re comment #7:

This is effective only for file-types using file extensions, not for URI protocols.
Ok, for win7, and vista i guess, it's definitely for protocols too. (Start -> Default Programs)
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Bug #575376 only addresses the FTP protocol.  This is a duplicate of bug #575376 only if the scope of that bug report is expanded to include other Internet protocols.
The scope of bug #575376 limited to FTP while the scope of this RFE is not limited to any specific Internet protocol.  Since no one has followed-up on my request to expand the scope of bug #575376, I am reopening this bug.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
It was pointed out in the mozilla.support.thunderbird (thread with subject: Helper Application) that there is no preset application for opening an RTF attachment (file with the .rtf extension).  I am expanding the scope of this RFE to encompass a general, user-oriented ability to add entries to the list obtained from [Tools > Options > Attachments] on the Thunderbird menu bar, not only for URI protocols but also for files attached to messages.
Summary: Need User Interface for Selecting Applications for non-http urls → Need User Interface for Selecting Applications for Non-HTTP URIs and for Various Attachments
See bug #806240 for a parallel SeaMonkey RFE.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.