258278 - Forwarding HTML RSS article to an email address results in an empty email message

Status: VERIFIED FIXED

(MailNews Core :: Feed Reader, defect)

Description

[David Brittain]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040906 Firefox/1.0 PR (NOT FINAL)
Build Identifier: version 0.8 (20040906)

If you have RSS article open and select Forward. Then the article appears in a
compose window and appears to allow you to send it to an email address. However
when the email arrives it only has a subject, date and sender, in the body of
the message, but it does not contain the contents of the article.

e.g. 



-------- Original Message --------
Subject: 	If there it's a 'one in a million' chance...
Date: 	Tue, 07 Sep 2004 14:11:42 GMT
From: 	<andersja>



Reproducible: Always
Steps to Reproduce:
1. Open RSS article
2. Select forward
3. Enter and email recipient and send

Actual Results:  
The email that arrives odes not contain the body of the article

Expected Results:  
The complete RSS article should be forwarded

Comment 1

[Scott MacGregor]

forwarding as inline is working for me in this test case for both HTML based RSS
pages and just the text versions. 

Comment 2

[David Brittain]

Fowarding text only articles works fine. I am also forwarding as inline. I have
tried a few HTML based RSS feeds and none seem to work. e.g. just tried the
slashdot article "New Star Trek MMOG Announced" all I recieve is the following:

-------- Original Message --------
Subject:     New Star Trek MMOG Announced
Date:     Tue, 07 Sep 2004 12:16:00 GMT
From:     <CmdrTaco>

Do you have any suggestions as to what else might be wrong?

Comment 3

[Kamil Jonca]

With Thunderbird 0.8 under Windows XP  forvarding HTML rss leading to crash.

Comment 4

[Richard Sbarro]

Using Thunderbird 0.8 under Windows XP, I can forward RSS articles inline, but
the URL for the article is not sent as well.  IMHO, it would be really useful if
the URL was included in the body of the forwarded article, either at the top or
the bottom.

Right now, I have to view the page in a browser (since you can't do a 'Copy Link
Location' on the Website URL) and copy/paste the URL from there into the message.

Comment 5

[Bill May]

I use text rather than html in my main account, so I also get the blank email to
send.  It would be useful to have a "send url" option, or include the url in 
the message body.

Comment 6

[Marcia Knous [:marcia]]

Setting TM to 1.0 for consideration.  Sarah was able to reproduce this easily
forwarding a HMTL RSS article (using the display entire web page setting) as inline.

Comment 7

[Scott MacGregor]

I'm hijacking this bug to cover a nasty issue when replying, forwarding, editing
as  new for RSS articles which are really web pages. 

If you try to reply to one of these articles, you can't actually type any text
in the compose window because the iframe of the RSS article is sized to take up
all available space. You can get around this by forwarding the article as an
attachment but then you get into the same problem when thunderbird loads the
message.

For now, let's try to fix all of these issues by routing all attempts to
reply/forward/edit as new an RSS article to just send the article link.

i.e. instead of loading the iframe content you'll just get a compose window with
the article URL as the message body and the subject set to the RSS article.
There won't be a FWD or RE in the subject. There won't be a To filled in with
the bogus name listed as the sender in the message pane for the feed. 

Comment 8

[Scott MacGregor]

Attachment: the fix is something like this....

Right now I'm getting the subject from nsIMsgHdr. I wonder if I also need to
set a charset on the compose properties...

David, here are the changes to nsParseMailboxState that I was talking to you
about. Do you want me to make sure the folder belongs to an RSS server before
trying to set a content base header?

Note: This fix will only work on new feed articles you download (unless you do
a reparse by deleting your .msf files like I did).

I think this needs some more polish before it is ready for review but wanted to
get the initial cut out there...

Comment 9

[Scott MacGregor]

David, there may be a way to fix this without making changes to the mailbox parser. 
It looks like the message ID for RSS articles has the form:

Message-Id:
<http://weblogs.mozillazine.org/ben/archives/[e-mail]>

and that is stored in the msg hdr already.

I could probably try to decompose that into a URL check if it begins with http
or https and conclude that the msg is an RSS msg if that is the case (I don't
think regular mail/news msgs would have a message id that begins with http or
https).

That avoids the mailbox parsing code and it would work for articles already
parsed unlike the current proposal. 

Comment 10

[Scott MacGregor]

Attachment: better fix that doesn't require changes to the mailbox parser

Comment 11

[Scott MacGregor]

Attachment: fix ready for review

Comment 12

[Scott MacGregor]

Comment on attachment 167324 [details] [diff] [review]
fix ready for review

1) uses the message ID and checks to see if it begins with http or https as the
indicator as to whether the msg is an RSS article or not. This means you can
move the RSS message somewhere else in the app and we'll still treat it special
on reply because we aren't looking for it being in an RSS server.

2) Parse out just the URL from the message ID set that as the body for a
compose window, fix up the Subject to include Re or FWD prefixes based on the
message type. Set the subject and charset on the compose window and then invoke
the compose window.

I like this approach a lot because it means:

1) don't have to worry about already parsed mailboxes like the previous
solution

2) no changes to the mailbox parser

3) works wherever the RSS message may be even if it is not under an RSS
account.

Comment 13

[Scott MacGregor]

I checked this into aviary so QA sees it when they starting their 1.0 BFTs
tomorrow. I'll make further changes as necessary based on David's review comments. 

Comment 14

[David :Bienvenu]

Comment on attachment 167324 [details] [diff] [review]
fix ready for review

you get and check composeService, but you use msgComposeService...

sr=bienvenu if you fix that... 

+	 var composeService =
Components.classes["@mozilla.org/messengercompose;1"]
+				       
.getService(Components.interfaces.nsIMsgComposeService);
+	 if (composeService) {
+	   try {
+	     params.identity = msgComposeService.defaultIdentity;
+	   }
+	   catch (ex) {
+	     params.identity = null;
+	   }
+	   msgComposeService.OpenComposeWindowWithParams(null, params);
+	 }

Comment 15

[Scott MacGregor]

fixed branch and trunk.

I also got rid of creating a msg compose service since it's a global variable
already.

Comment 16

[sairuh (rarely reading bugmail)]

thanks for fixing this! tested with 20041201-0x-0.9 on linux and mac.

- fwd (inline and attachment) now just brings up a mail compose window with the
url of the article (for both summary text and full webpage).

- reply/reply all also just bring up a mail compose window with the url of the
article (for both summary text and full webpage). moreover, the To: field is
empty (as it should be :).

Comment 17

[A. Sapuntzakis]

> - fwd (inline and attachment) now just brings up a mail compose window with the
> url of the article (for both summary text and full webpage).

So what happens now with articles which have (functional) "teaser text" (i.e.
slashdot) as well as URLs to the full entry - does the text no longer make it
into the email? If so, shouldn't that be logged now?