Bug 490308 - thunderbird fails to properly attach source for HTML link
thunderbird fails to properly attach source for HTML link
Product: Fedora
Classification: Fedora
Component: thunderbird (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Jan Horak
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-03-15 00:38 EDT by Jonathan Kamens
Modified: 2009-08-10 17:12 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-08-10 17:12:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
example of reproducing this bug (2.00 KB, text/plain)
2009-03-26 13:44 EDT, Matěj Cepl
no flags Details
Script for coredump analysis (378 bytes, text/plain)
2009-06-18 16:15 EDT, Matěj Cepl
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 509541 None None None Never

  None (edit)
Description Jonathan Kamens 2009-03-15 00:38:01 EDT
With thunderbird-3.0-1.beta2.fc11.i586:

Compose an email message containing no HTML formatting except for a link whose text is identical to the link location.  In the Link Properties dialog, check the "Attach the source of this link to the message" checkbox.  Send the message.

The message will be sent as plaintext rather than as HTML or as multipart/alternative.  This is the first bug.  If I insert a link into a message, then that's HTML markup, and I expect HTML to be generated for the message, dammit.

The second bug is that it fails to properly attach the source of the link as you told it to do.  It inserts a "cid:" marker in the text of the message, but this marker is useless because the indicated content ID isn't actually attached to the message (and because it's a plaintext message rather than HTML).

If you put other HTML formatting into the message, e.g., bold or italic text, then the message is sent as HTML and the attachment is included as requested.
Comment 1 Matěj Cepl 2009-03-26 13:44:06 EDT
Created attachment 336852 [details]
example of reproducing this bug
Comment 2 Matěj Cepl 2009-03-26 13:45:40 EDT
And BTW, User-Agent is wrong ... this was really sent from thunderbird-3.0-1.beta2.fc11.x86_64
Comment 3 Bug Zapper 2009-06-09 08:14:50 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
Comment 4 Stephen Gallagher 2009-06-10 11:55:59 EDT
I am also seeing this bug. I'm not sure if it's a Fedora bug or an upstream bug, so I have opened https://bugzilla.redhat.com/show_bug.cgi?id=490308 upstream.

Of note, I've lately been seeing this bug manifest itself only for http:// links, not https:// links.
Comment 5 Matěj Cepl 2009-06-10 12:15:46 EDT
(In reply to comment #4)
> I am also seeing this bug. I'm not sure if it's a Fedora bug or an upstream
> bug, so I have opened https://bugzilla.redhat.com/show_bug.cgi?id=490308
> upstream.

Sorry, what is the upstream bug number, please?
Comment 6 Stephen Gallagher 2009-06-10 12:59:57 EDT
Sorry, I botched the copy-paste: https://bugzilla.mozilla.org/show_bug.cgi?id=493204
Comment 7 Matěj Cepl 2009-06-18 16:15:28 EDT
Created attachment 348552 [details]
Script for coredump analysis

If you are not able to collect backtrace by hand, use the attached script, please.
Thread 1 (Thread 9115):
#0  0x00000035aa60ed5b in raise (sig=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:42
#1  0x00000035bb873244 in nsProfileLock::FatalSignalHandler (signo=11)
    at nsProfileLock.cpp:212
#2  <signal handler called>
#3  nsPluginInstancePeerImpl::GetJSContext (this=0x7fc47a490290, 
    outContext=0x7fff974a66d8) at nsPluginInstancePeer.cpp:805
#4  0x00000035bc091154 in map_jsj_thread_to_js_context_impl (
    jsj_env=<value optimized out>, java_applet_obj=<value optimized out>, 
    env=<value optimized out>, errp=<value optimized out>) at lcglue.cpp:138
#5  0x00000035bc192bc4 in jsj_enter_js (jEnv=0x7fc479f5e4c0, 
    applet_obj=0x7fc47f6b4160, java_wrapper_obj=<value optimized out>, 
    cxp=0x7fff974a6850, js_objp=<value optimized out>, 
    old_error_reporterp=0x7fff974a6848, pNSIPrincipaArray=0x0, 
    numPrincipals=0, pNSISecurityContext=0x0) at jsj_JSObject.c:754
#6  0x00000035bc19bef8 in nsCLiveconnect::GetWindow (this=0x7fc479e9a760, 
    jEnv=0x7fc479f5e4c0, pJavaObject=0x7fff974a66d8, principalsArray=0x0, 
    numPrincipals=<value optimized out>, securitySupports=0x0, 
    pobj=0x7fc47f6b4188) at nsCLiveconnect.cpp:668
#7  0x00007fc4793e4e59 in IcedTeaPluginInstance::GetWindow (
    this=0x7fc47f6b4160) at IcedTeaPlugin.cc:4150
#8  0x00007fc4793f0009 in IcedTeaRunnableMethod<IcedTeaPluginInstance>::Run (
    this=0x7fc479c344c0) at IcedTeaPlugin.cc:1429
#9  0x00000035bc14874d in nsThread::ProcessNextEvent (this=0x7fc48f13b790, 
    mayWait=1, result=0x7fff974a695c) at nsThread.cpp:510
#10 0x00000035bc119f10 in NS_ProcessNextEvent_P (thread=0x7fff974a6690, 
    mayWait=-1756731688) at nsThreadUtils.cpp:227
#11 0x00000035bc0732d9 in nsBaseAppShell::Run (this=0x7fc488d41040)
    at nsBaseAppShell.cpp:170
#12 0x00000035bbf23a14 in nsAppStartup::Run (this=0x7fc487ba4f00)
    at nsAppStartup.cpp:193
#13 0x00000035bb86d4f8 in XRE_main (argc=<value optimized out>, 
    argv=<value optimized out>, aAppData=<value optimized out>)
    at nsAppRunner.cpp:3298
#14 0x00000000004022ab in main (argc=<value optimized out>, 
    argv=0x7fff974aa3a8) at nsXULStub.cpp:385
Current language:  auto; currently asm
Current language:  auto; currently minimal
Comment 8 Matěj Cepl 2009-06-18 16:17:26 EDT
Andrew, isn't this something Java-related?
Comment 9 Andrew Overholt 2009-06-18 16:24:58 EDT
It does indeed look browser plugin-related.  Deepak is the author.
Comment 10 Deepak Bhole 2009-06-18 17:12:12 EDT
How did you produce that traceback (i.e. steps to reproduce)? I can get the click to not work, but gdb does not show any threads stopped in raise(), nor does it catch any awry signals ...:

(gdb) info threads
  21 Thread 0xad29db90 (LWP 4248)  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_timedwait.S:180
  14 Thread 0xb00ffb90 (LWP 4135)  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_timedwait.S:180
  13 Thread 0xb10ffb90 (LWP 4134)  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_timedwait.S:180
  12 Thread 0xb53ffb90 (LWP 4133)  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_timedwait.S:180
  10 Thread 0xb2cffb90 (LWP 4131)  0x009a6f60 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
  9 Thread 0xb36ffb90 (LWP 4129)  0x009a6f60 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
  8 Thread 0xb6151b90 (LWP 4128)  0x009a6f60 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
  7 Thread 0xb47ffb90 (LWP 4127)  0x009a6f60 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
  3 Thread 0xb6cffb90 (LWP 4123)  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_timedwait.S:180
  2 Thread 0xb77ffb90 (LWP 4122)  0x008cc82d in __poll (fds=0xb77fee68, nfds=2, timeout=65535000) at ../sysdeps/unix/sysv/linux/poll.c:87
* 1 Thread 0xb7fd3760 (LWP 4113)  0x008cc82d in __poll (fds=0xb3ca8580, nfds=12, timeout=3868) at ../sysdeps/unix/sysv/linux/poll.c:87
Comment 11 Jonathan Kamens 2009-06-25 18:00:21 EDT
I don't see what information you're asking me for.
Comment 12 Deepak Bhole 2009-06-26 15:06:13 EDT
Sorry for the confusion. Matej, I need to know the steps you took to produce that gdb trace in Comment #7
Comment 13 Matěj Cepl 2009-06-27 09:08:46 EDT
(In reply to comment #12)
> Sorry for the confusion. Matej, I need to know the steps you took to produce
> that gdb trace in Comment #7  

I am really sorry, I screwed up, everything from comment 7 included should go to bug 506692 (which probably shouldn't be closed as it is).
Comment 14 Matěj Cepl 2009-08-10 17:12:44 EDT
(In reply to comment #6)
> Sorry, I botched the copy-paste:
> https://bugzilla.mozilla.org/show_bug.cgi?id=493204  

Shut, I haven't checked the link and now I have included my comment to totally irrelevant bug. Actually, I haven't found any upstream bug from you for this issue. Filing a new one in the upstream database (https://bugzilla.mozilla.org/show_bug.cgi?id=509541), because I believe that it is more appropriate to let it be resolved upstream.

We will continue to track the issue in the centralized upstream bug tracker, and will review any bug fixes that become available for consideration in future updates.

Thank you for the bug report.

Note You need to log in before you can comment on or make changes to this bug.