Closed Bug 272519 Opened 20 years ago Closed 9 years ago

No help; and clicking link in message does not open page in browser

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Platform:
x86
Windows ME
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: actaylor, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1
Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1

All links in email text do not connect. I have Firefox up and running prior to
clicking on link. Also, the help feature does not work -- which I think is
probably a link to a web page, so probably is the same problem. This feature did
not work with Thunderbird .8 or .9

Reproducible: Always
Steps to Reproduce:
1.Get email with link (such as your email with my password)
2.Click on link
3.Address turns red but nothing happens.

Actual Results:  
Same as always -- nothing

Expected Results:  
Link to web page
Hm.  I'm going to confirm this because I've got the same symptom (I hadn't 
noticed that the Help menu items weren't working) with Windows 2000.  However, 
it was working for me with TB 0.8; it was with 0.9 that links stopped working.

Windows ME doesn't have the built-in support for "default browser" but that 
shouldn't make a difference.  Please report your settings for the system HTTP 
handler:
  Windows Explorer: Tools | Folder Options | File Types tab
  scroll down and select "URL: Hyper Text Transfer Protocol"; click Edit
  select "open"; click Edit again
Please report all settings on this window.

For my system (currently with TB 0.9+1126), the settings are:
  Application:   <path>\Opera.exe
  Use DDE: checked
  DDE message:   "%1"
  Application:   Opera
  DDE Application not running:  <blank>
  Topic:         WWW_OpenURL
but I get the same results (or rather, lack of results) if the DDE box is 
unchecked.

Xref bug 252563 and bug 265008.

Unfortunately, links are working to open in the browser for practically all TB 
users; you and I are in a small minority here, and we have to figure out the 
settings that are causing this problem.
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: From Thunderbird email msg, links to web and help do not connect (Firefox already up) → No help; and clicking link in message does not open page in browser
*** Bug 274598 has been marked as a duplicate of this bug. ***
Hi, 
 
> Unfortunately, links are working to open in the browser for practically all 
TB  
> users; you and I are in a small minority here, and we have to figure out the  
> settings that are causing this problem. 
 
I have the same problem, in windows it works, but in linux __nothing ever 
happened__ when I clicked on a link in TB 0.9 and now 1.0. This also affects 
plain text messages and I have set konqueror as default browser as described in 
http://kb.mozillazine.org/index.phtml?title=Setting_Your_Default_Browser#Linux_(KDE) 
. Although ".html" is rather rare in URLs, I sent myself a mail with a URL to 
a .html-File and still nothing happened. 
 
This affects both the german and the english version of TB 1.0 on my SuSE 9.2. 
 
http://lists.debian.org/debian-user-german/2004/12/msg00486.html recommends 
setting user_pref("network.protocol-handler.app.http", "/usr/bin/firefox"); but 
that does not work either (I used it with "/usr/local/mozilla/mozilla" of 
course) 
 
Maybe this helps: I downloaded firefox, started it and denied setting it as
default browser. Then I went in TB and everything was the same - no links
worked. Then I exited TB, started FF again and this time allowed it to set
itself als standard browser. Now links in TB open the firefox browser.

Where does Firefox get the information what the default browser is from? Where
does it store the setting that it is the default browser?
I have found the problem in my installation: my prefs.js file has:
  user_pref("network.protocol-handler.external.http", false);
  user_pref("network.protocol-handler.external.https", false);

If I set this true, links and help work.  Unfortunately, if I reset those to 
true, RSS feeds are *also* thrown to the browser.  This is very unhelpful.

I wonder if this change has something to do with bug 263546; I don't really 
understand what those  protocol-handler.expose  prefs are for.  CC'ing Christian 
to see if he can provide a hint.


(In reply to comment #3)
> I have the same problem, in windows it works, but in linux __nothing ever 
> happened__ when I clicked on a link in TB 0.9 and now 1.0. 

jstaerk:  That is not this problem.  *nix installations do not have a "default 
browser" so the system has nothing to refer to when the http link is being 
processed.  Is comment 4 about Windows or Linux?
> (In reply to comment #3)
> > I have the same problem, in windows it works, but in linux __nothing ever 
> > happened__ when I clicked on a link in TB 0.9 and now 1.0. 
> 
> jstaerk:  That is not this problem.  *nix installations do not have a "default 
> browser" so the system has nothing to refer to when the http link is being 
> processed.  Is comment 4 about Windows or Linux?

Comment 4 is about SuSE Linux 9.2. I _know_ that there is no such thing as a
default browser in linux, yet the FB installation says "Firebird is not your
default browser. Do you wish to make it the default browser?" unless you clicked
on "yes". 

My theory is that FB and TB have a setting for a default browser. This could
e.g. be an environment-variable or a file somewhere. I run  "env | grep
firebird" but no env matched. 

The theory that there might be some env variable seemed especially persuading to
me because I installed FB with the installer whereas SeaMonkey was only
unpacked. There is a directory /usr/local/init.d where the README says there use
to be startup scripts (there are no other files in that dir). So, if a unixoid
user was supposed to install something e.g. in his/her profile, this could have
somehow explained most of the behaviour of SeaMonkey, TB and FB.
Hi,
>   user_pref("network.protocol-handler.external.http", false);
>   user_pref("network.protocol-handler.external.https", false);
> 
> If I set this true, links and help work.  Unfortunately, if I reset those to 
> true, RSS feeds are *also* thrown to the browser.  This is very unhelpful.

In my TB installation prefs.js, there is no such thing as 
user_pref("network.protocol-handler.external.http...
or user_pref("network.protocol-handler.external.https
... you are referring to windows TB, aren't you?

is there somewhere some kind of prefs-reference where one could look up which
prefs arre affecting TB? My search ended up in some site called the "hidden
prefs.js reference" which is really not complete at all.
(In reply to comment #7)
> >   user_pref("network.protocol-handler.external.http", false);
> >   user_pref("network.protocol-handler.external.https", false);
> > 
> > If I set this true, links and help work.  Unfortunately, if I reset those to 
> > true, RSS feeds are *also* thrown to the browser.  This is very unhelpful.
> 
> In my TB installation prefs.js, there is no such thing as 
> user_pref("network.protocol-handler.external.http...
> or user_pref("network.protocol-handler.external.https
> ... you are referring to windows TB, aren't you?

My prefs were in Windows but I think the protocol-handler.extern settings are 
cross-platform.  Most prefs are not written into the file unless their values 
differ from the default.  You can try adding those lines to see if they make a 
difference, set either to true or false. (I don't know offhand what the default 
is, and the default might even be different between Windows and *nix.)

I found this at bug 11459 comment 218:
> In Mozilla 1.7 on Red Hat 9, I was doing this, and it worked:
>    user_pref("network.protocol-handler.external.mailto", "true");
>    user_pref("network.protocol-handler.app.mailto", "gsendmail");

You can try adding lines like that, for http and https, to your TB prefs.js (or 
create a user.js file to hold those settings), to see if they work.

See also bug 33282, bug 56478, and bug 128668 & bug 140635 (Gnome).
>   user_pref("network.protocol-handler.external.http", false);

setting this to false does nothing (it is the default setting, though not
explicitly mentioned in all.js). setting it to true makes mozilla never use its
own http handler for any http requests, and instead call the external one.


I don't fully understand the expose prefs, but afaik they mean: use the external
protocol handler for "link clicks", the internal one for the rest.
> *nix installations do not have a "default browser" 

gnome does though, and mozilla uses that.
>In my TB installation prefs.js, there is no such thing as 
>user_pref("network.protocol-handler.external.http...
>or user_pref("network.protocol-handler.external.https
>... you are referring to windows TB, aren't you?

these prefs can be set on each platform, but (from the point of view of the
prefs module) they do not have a default value and thus are not listed in
about:config.
Christian, thanks for your input -- I'm not sure if you noticed that this is a 
Thunderbird bug; the settings you talk about seem more appropriate for a 
browser.

I tried making various changes to the protocol-handler.expose preferences with 
no success.  However, I did manage to get both links and RSS feeds working 
correctly -- by *removing* the p-h.extern.http(s) preferences, rather than 
changing their values.  The defaults for these are true, but apparently 
*setting* them to true results in some other change internally...?  Odd 
behavior, but my problem is fixed.

After email exchange with the original reporter of this bug, the configuration 
on that computer has been fixed and links are working.


jstaerk, I am going to close this bug even tho the status to your problem is 
still unresolved; this was originally a Windows bug and it makes no sense to 
maintain it open for a known issue with Linux and BSD.  If the referenced bugs 
in comment 8 did not help, please open a new bug for your problem.

Marvin Skorman, I think your bug was duped incorrectly; please check out 
bug 271756.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
>Christian, thanks for your input -- I'm not sure if you noticed that this is a 
>Thunderbird bug; the settings you talk about seem more appropriate for a 
>browser.

I did notice that; the settings work the same for each app. you do want to load
imap:// urls inside of thunderbird, no?


(In reply to comment #11)
> >In my TB installation prefs.js, there is no such thing as 
> >user_pref("network.protocol-handler.external.http...
> >or user_pref("network.protocol-handler.external.https
> >... you are referring to windows TB, aren't you?
> 
> these prefs can be set on each platform, but (from the point of view of the
> prefs module) they do not have a default value and thus are not listed in
> about:config.

How do you go about editing this settings. I am still experiencing this issue,
and I think I have looked at all other avenues.

I directly edited the prefs.js file, but after I saved and reopened TB, the
lines I pasted in (the ones from above) were gone.

Thoughts.

(In reply to comment #14)
> (In reply to comment #11)
> > >In my TB installation prefs.js, there is no such thing as 
> > >user_pref("network.protocol-handler.external.http...
> > >or user_pref("network.protocol-handler.external.https
> > >... you are referring to windows TB, aren't you?
> > 
> > these prefs can be set on each platform, but (from the point of view of the
> > prefs module) they do not have a default value and thus are not listed in
> > about:config.
> 
> How do you go about editing this settings. I am still experiencing this issue,
> and I think I have looked at all other avenues.
> 
> I directly edited the prefs.js file, but after I saved and reopened TB, the
> lines I pasted in (the ones from above) were gone.
> 
> Thoughts.
> 

1. Be sure TB does not run when you edit prefs.js. Otherwise all changes will
probably overwritten.

2. You need not two but four new lines in your prefs.js file:

user_pref("network.protocol-handler.external.http", true);
user_pref("network.protocol-handler.external.https", true);
user_pref("network.protocol-handler.app.http", "/usr/local/firefox/firefox");
user_pref("network.protocol-handler.app.https", "/usr/local/firefox/firefox");

where of coure you substitute "/usr/local/firefox/firefox" with whatever command
that makes firefox run on your system. At least this was the setting that got my
configuration going...
I am still experience this problem with TB 1.02 Build 20050317 and FF 1.02.

My prefs.js file says this in it:

user_pref("network.protocol-handler.app.http", "c:/program
files/mozilla/FireFox/firefox.exe");
user_pref("network.protocol-handler.app.https", "c:/program
files/mozilla/FireFox/firefox.exe");
user_pref("network.protocol-handler.external.http", true);
user_pref("network.protocol-handler.external.https", true);

Is that right?

Please help.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(In reply to comment #16)
> I am still experience this problem with TB 1.02 Build 20050317 and FF 1.02.
> 
> My prefs.js file says this in it:
> 
> user_pref("network.protocol-handler.app.http", "c:/program
> files/mozilla/FireFox/firefox.exe");
> user_pref("network.protocol-handler.app.https", "c:/program
> files/mozilla/FireFox/firefox.exe");
> user_pref("network.protocol-handler.external.http", true);
> user_pref("network.protocol-handler.external.https", true);
> 
> Is that right?

Not right.  Per comment 12, for WINDOWS installations, remove *all* those lines, 
which lets Thunderbird run with its defaults.

I think the protocol-handler.app prefs are Linux-only.
I am also experiencing the lack of clickable links from Thunderbird to Firefox.
The browser opens up, but the URL doesn't get pasted into the URL bar. I have
just upgraded to the latest Firefox v1.03, and I have the latest Thunderbird
v1.0.  This feature did work in the first version of Firefox that I had, and I
believe it disappeared after I did a secureity update.

Chris
*** Bug 293090 has been marked as a duplicate of this bug. ***
*** Bug 294449 has been marked as a duplicate of this bug. ***
*** Bug 293027 has been marked as a duplicate of this bug. ***
*** Bug 297014 has been marked as a duplicate of this bug. ***
*** Bug 297013 has been marked as a duplicate of this bug. ***
I have a similar issue in Win XP with Thunderbird 1.0.7 and version 1.5 Beta 2 (20051006), but am able to report an easy work-around. If you go to "Set Program Access and Defaults" and change the "Choose a default Web browser" from "Use my current Web browser" to "Mozilla Firefox" and everything works fine. Just FYI.
QA Contact: front-end
I just installed Thunderbird 2.0 and have noticed that the "Help", "Release Notes", and links with in the e-mail body do not open at all.  I am running Windows XP Professional.


this tends to happen when you don't have a default browser set. Try re-setting your browser as the default.
Hi Scott, 

I have tried resetting my default browser and even reloading and it still happens.
I found out how to fix my issue:
1. Open IE and set that to default
2. Close IE
3. Open Mozilla and have it check to see if it is the default browser
4. Set Mozzilla as the default browser

This is what I did and it worked to solve this problem.
i can comfirm this bug, i have gentoo linux and using firefox everything is the latest version.

when i recieve a mail with a link nothing will happen.

reg.
lanoxx
(In reply to comment #28)
> I found out how to fix my issue:
> 1. Open IE and set that to default
> 2. Close IE
> 3. Open Mozilla and have it check to see if it is the default browser
> 4. Set Mozzilla as the default browser
> 
> This is what I did and it worked to solve this problem.
> 
I can confirm this solves the problem. URLs now open in email and the TB help menus now work. After proceeding as above I also notice the following system changes:

In the Windows Registry :
HKEY_CLASSES_ROOT\HTTP\shell has a new "open" variable which wasn't there before, now set to Firefox

In the File Types:
For URL link, the open variable now has "rundll32.exe shdocvw.dll,OpenURL %l" instead of \Firefox.exe as previously. (Hence the IE icon appears as the association, but in fact Firefox opens - very counterintuitive)

As regards the prefs.js files, I did not have any refs to p-h.external.http before and still don't.

I'm using Firefox/2.0.0.11 and Thunderbird 2.0.0.9 on Windows Pro XP + SP2

This problem looks like as a duplicate of 
Bug 399624
Bug 326567  
which still appear to be unresolved.

Thank to everybody for your invaluable support.
Prem
Assignee: mscott → nobody
Status: REOPENED → NEW
Along the lines of comment 31, does anyone still see this problem?
Whiteboard: [closeme 2015-03-25]
Resolved per whiteboard
Status: NEW → RESOLVED
Closed: 20 years ago → 9 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2015-03-25]
You need to log in before you can comment on or make changes to this bug.