Description of problem: When I get an e-mail message with a URL in it, I would normally be able to click on that link and Firefox would open it. Now when I click on the link FF doesn't "see" the protocol or hostname as part of the URL. For instance, if I try to open up a link to http://www.yearone.com/images/email/c146/turkeydayemail.html, Firefox tries to open file:///images/email/c146/turkeydayemail.html and I get a "File Not Found" error. Version-Release number of selected component (if applicable): thunderbird-2.0.0.18-1.fc10.x86_64 firefox-3.0.4-1.fc10.x86_64 How reproducible: Click on a link in an e-mail message. Steps to Reproduce: 1. Open a message in Thunderbird which has a link 2. Click on link 3. Curse Actual results: FF attempts to open everything after the protocol and hostname. Expected results: It should open the whole URL. Additional info: Fedora 10 x86_64 on an Athlon 64 4600+ with 2GiB memory. Updated today (2 December 2008).
Tried to run strace -ff -o tbird.log against Thunderbird to capture more information. It did capture numerous log files, but then it crashed with: [thomas.cameron@case strace]$ strace -ff -o tbird.log thunderbird *** glibc detected *** strace: malloc(): memory corruption (fast): 0x00000000010dcbe0 *** ======= Backtrace: ========= /lib64/libc.so.6[0x34d0877e98] /lib64/libc.so.6[0x34d087b531] /lib64/libc.so.6(__libc_malloc+0x98)[0x34d087ca08] strace[0x408728] strace[0x40598e] strace[0x404696] /lib64/libc.so.6(__libc_start_main+0xe6)[0x34d081e546] strace[0x401e69] ======= Memory map: ======== 00400000-00447000 r-xp 00000000 08:02 415181 /usr/bin/strace 00647000-00648000 rw-p 00047000 08:02 415181 /usr/bin/strace 00648000-00656000 rw-p 00648000 00:00 0 00847000-00848000 rw-p 00047000 08:02 415181 /usr/bin/strace 010dc000-010fd000 rw-p 010dc000 00:00 0 [heap] 34cf000000-34cf020000 r-xp 00000000 08:02 786533 /lib64/ld-2.9.so 34cf21f000-34cf220000 r--p 0001f000 08:02 786533 /lib64/ld-2.9.so 34cf220000-34cf221000 rw-p 00020000 08:02 786533 /lib64/ld-2.9.so 34d0800000-34d0968000 r-xp 00000000 08:02 786932 /lib64/libc-2.9.so 34d0968000-34d0b68000 ---p 00168000 08:02 786932 /lib64/libc-2.9.so 34d0b68000-34d0b6c000 r--p 00168000 08:02 786932 /lib64/libc-2.9.so 34d0b6c000-34d0b6d000 rw-p 0016c000 08:02 786932 /lib64/libc-2.9.so 34d0b6d000-34d0b72000 rw-p 34d0b6d000 00:00 0 3e38200000-3e38216000 r-xp 00000000 08:02 787793 /lib64/libgcc_s-4.3.2-20081105.so.1 3e38216000-3e38416000 ---p 00016000 08:02 787793 /lib64/libgcc_s-4.3.2-20081105.so.1 3e38416000-3e38417000 rw-p 00016000 08:02 787793 /lib64/libgcc_s-4.3.2-20081105.so.1 7ff760000000-7ff760021000 rw-p 7ff760000000 00:00 0 7ff760021000-7ff764000000 ---p 7ff760021000 00:00 0 7ff7648b9000-7ff764913000 rw-p 7ff7648b9000 00:00 0 7ff764915000-7ff76492f000 rw-p 7ff764915000 00:00 0 7fff6c919000-7fff6c92e000 rw-p 7ffffffea000 00:00 0 [stack] 7fff6c9fe000-7fff6c9ff000 r-xp 7fff6c9fe000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted
Created attachment 325415 [details] Output of strace -ff This is what was captured by strace before it died.
As an additional test, I deleted the .thunderbird and .mozilla directories from my home directory. The problem persists for my user.
What was the URL you tried to open when generating the strace? grep turkey strace/* doesn't give me anything. And BTW, uncompressed output of strace -f (notice one f) would be probably more easy to handle.
OK, I will upload a new strace. In this one, I am trying to open a link to http://www.facebook.com/n/?inbox/readmessage.php&t=1064274559729 but when the browser opens it tries to open /n/?inbox/readmessage.php&t=1064274559729 and I get a "file not found" error. Another thing that I found is weird is that it only happens when I su - to another account. When I'm working from home, I log in to my F10 box as tcameron and do all my Red Hat stuff under that login. On a different desktop, I open a gnome-terminal, do "su - thomas.cameron" and run thunderbird& so I can check my personal e-mail at the same time but on a different desktop. When I do that, I see the weird behavior. If I log out and then log in as thomas.cameron, it works correctly.
Created attachment 325535 [details] uncompressed output of strace -f
weird, it seems we are doing The Right Thing 20161 execve("/usr/lib64/thunderbird-2.0.0.18/open-browser.sh", ["/usr/lib64/thu nderbird-2.0.0.18/"..., "http://www.facebook.com/n/?inbox"...], [/* 47 vars */] <unfinished ...>
I am also experiencing this bug, and hopefully have some relevant info to add. My uname -a displays: 2.6.27.12-170.2.5.fc10.i686 #1 SMP Wed Jan 21 02:09:37 EST 2009 i686 athlon i386 GNU/Linux packages installed: thunderbird-2.0.0.19-1.fc10.i386 firefox-3.0.6-1.fc10.i386 libgnome-2.24.1-7.fc10.i386 When I click on an URL link in thunderbird: * thunderbird calls /usr/lib/thunderbird-2.0.0.19/open-browser.sh * open-browser.sh calls /usr/bin/gnome-open * gnome-open eventually starts firefox with the incorrect link If I open up a gnome-terminal and cd to /etc/samba and then issue the command: gnome-open http://google.com then I end up with firefox opened to "file:///etc/samba/" If start firefox directly "firefox http://google.com" then I do get the correct link. Please note that I am running in a VNCServer ICEWM session. This thunderbird URL link used to work in this same VNC environment with my previous Fedora installation (FC6). The "gnome-open" command above successfully opens the correct URL with firefox when I am logged into a different account using a Gnome session. This looks to me like a "gnome-open" issue. Curtis.
Created attachment 338006 [details] Patch to open-browser.sh to use xdg-open, which better handles URL passing This patch against /usr/share/thunderbird-2.0.0.21/open-browser.sh attempts to use xdg-open as the preferred handler for URL-launching, since it does the right thing when thunderbird and firefox are running on different hosts (but on same display).
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.