Closed Bug 239226 Opened 20 years ago Closed 20 years ago

Opening Forward Message Attachment Opens parent message in a new window


(Thunderbird :: Mail Window Front End, defect)

Windows XP
Not set


(Not tracked)



(Reporter: bugs, Assigned: mscott)


(Keywords: regression)


(1 file)

In a trunk build (Mozilla Thunderbird 0.5+ (20040329)) when I have a message
from someone containing a forwarded message as an attachment, opening the
forwarded message in a new window by double clicking the attachment does not work. 

Steps to reproduce:
1) Preview an email containing a forwarded message as an attachment.
2) Double click the attachment to view the forwarded message in a new Mail window

Expected results:
- view the email attachment by itself in a new window

Actual results:
- parent email message itself (the one that contains the forwarded email
attachment) opens in a new window

As a result it is impossible to read most forwarded emails.
this used to work
Target Milestone: --- → Thunderbird0.6
I know this used to work not that long ago. I'm not sure what broke it. I will
the regression is imap only. Moving it to a local folder and things still work fine.

When opening the attachment the url for the attachment looks like:

This then gets turned into the following url by the imap service when it is run:

The structure of the url looks good. We just don't seem to be streaming the part
out correctly anymore for imap.
i don't remember it ever working. i've been using seamonkey for imap for a while
now. i was going to mark this w/ dupeme, but this is a thunderbird bug.
this has worked for over a year until just recently. It was turned on in April
of 2003 and it worked in Thunderbird 0.5 so it's a very recent regression.

Bug #143565 is the bug that implemented this feature.
the last working build for this was on the 18th of February. The string
defragmentation branch landed on that day and nothing really changed in
mailnews. My guess is we are looking for one of those subtle string change
regressions probably somewhere in libmime where we decide to extract a part from
a message stream.
(In reply to comment #0)

Ben Goodger, your problem is same as Mozilla Mail&News bug 203570?
> [message/rfc822] opening a fwd local message has original messages's attachments
nope that's a separate issue that has never worked. This is a regression please
read the comments above :)
Interesting, using a debug 0.5 build and comparing it to a debug trunk build
that has the problem, I see the following:

The URL sent to nsMessengerContentHandler::HandleContent which we then turn
around and open in a stand alone message window looks like:


+	mStr	0x033f6af8

Note the lack of a question mark before the part=1.2 string in the url

Attached patch the fixSplinter Review
The problem was caused by the string defragmentation landing. The url string we
were trying to run was getting mutated out from underneath the nsIImapUrl
Comment on attachment 145295 [details] [diff] [review]
the fix

asking Darin for the r=. This was a regression caused  by the string
defragmentation landing. The code in question was causing the url spec for the
underlying nsIURI being run to get modified inadvertantly. I'm calling
BeginWriting on the nsCAutoString before we attempt to modify the underlying

Is this ok Darin?
Attachment #145295 - Flags: superreview?(bienvenu)
Attachment #145295 - Flags: review?(darin)
Comment on attachment 145295 [details] [diff] [review]
the fix

ok with me if it's ok with Darin.
Attachment #145295 - Flags: superreview?(bienvenu) → superreview+
this regression fix is going to need 1.7 final status I think...I'll ask over
Keywords: regression
a=chofmann for the trunk if it looks good to darin.  is this seamonkey too?
Comment on attachment 145295 [details] [diff] [review]
the fix

>Index: nsImapProtocol.cpp

>+  char * urlString;
>+  urlSpec.BeginWriting(urlString);
>   // for now, truncate of the query part so we don't duplicate urls in the cache...
>+  char * anchor = (char *)strrchr(urlString, '?');

you can also write this as a shorthand:

  char * anchor = (char *)strrchr(urlSpec.BeginWriting(), '?');

thank dbaron for adding a BeginWriting() that returns the iterator :-)

Attachment #145295 - Flags: review?(darin) → review+
I just filed bug 239405 on the general problem exposed by this bug.  I'll search
the rest of the tree for similar problems.  Wish me luck! :-)
I checked in the fix using Darin's suggested shorthand notation. Please note
this effects Thunderbird and seamonkey
Closed: 20 years ago
Resolution: --- → FIXED
I can confirm this has been fixed in Seamonkey
  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040402
You need to log in before you can comment on or make changes to this bug.