User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5 Build Identifier: 0.7pre (build 2007071803) nightly I've received a couple of event invitations from a Google calendar account, Lightning displays the event invitation box (which doesn't wrap within the frame width but that's another matter), however included messages are not visible. This happens independently of whether view attachments inline is on or off. Without Lightning installed TB shows the message and an invite.ics attachment. With Lightning installed TB shows the 'This message contains an invitation' bar, the invitation itself in the message frame and attachments 'Part 1.1.1' and 'invite.ics'. The comment does not appear. Reproducible: Always Steps to Reproduce: 1. Create an event on Google and add your Thunderbird email to the guest list 2. On Google calendar select the 'send message to guests option' and send a message. Actual Results: 3. With Lightning installed the message in the second email received is only visible via view-source if you know where to look. Expected Results: 3. The message is visible.

Also in: Lightning 0.5 WinXP Lightning 0.5 Linux (Fedora 7) Lightning 0.7pre nightly 2007072203 Linux (Fedora 7)

Reporter- please can you re-test it with latest nightly build? Can you try with a new profile? I can't reproduce it with Thunderbird 2.0.0.6 and Lightning 0.5 (Windows XP)

Just tried again with a new profile for both: Thunderbird 2.0.5, Lightning 0.5, Linux Thunderbird 2.0.5, nightly (09-Aug-2007 04:14), Linux With the nightly I tried the various combinations of original HTML/simple HTML/plain text and attachments inline. TB is the Fedora 7 packaged one. Will test on WinXP later with 2.0.6 if I get the chance. N.B. that the message is the part not visible, the event details box is visible in both the invitation and update emails.

Also in TB 2.0.6, Lightning nightly (09-Aug-2007 04:14), Windows Vista An offending example is attached. Without Lightning installed it is possible to see "this is a test event message", with Lightning installed all I see is the invitation (description "this is a test event description").

This might be true for every email invitation (not only Google ones) with an attached iCalendar file and following line "Content-Type: text/calendar; method=REQUEST; charset=ISO-8859-1". I don't know what the expected behavior is when there also exists text in the email itself.

The text should be shown above the parsed calendar invitation.

Does this still happen with the latest 1.0b2pre nightlies?

Yes, i have the latest 3.1 RC1 (build3) with 1.0b2pre from May 23rd 2010 and it's still shown as "part 1.1.1" attachment

might this be a thunderbird issue?

This is still an issue with the latest nightly build of Lightning (Dec 22nd, 2010). The message that's added to the notification using Google Calendar is not shown in the Event Invitation box when the email is viewed in Thunderbird. You can see the message embedded in an attachment when you view the source of the message but that's not very helpful.

This is still an issue in Thunderbird 5 / Lightning 1.0b5 When Lightning is disabled, the Thunderbird handles the email nicely: it displays both the relevant invite data and the message text that goes along with it. It seems that Lightning only parses the vcal to display the data, which does not contain the message sent along with the invite. If there is something I can do to help move this bug along towards being fixed, I'd be happy to help.

Unfortunately aside from coding there's probably not much you could do. If you'd like to dive in there, I'll be happy to provide you with the needed info though.

Comment on attachment 551862 [details] [diff] [review] This is a diff for chrome/lightning/skin/lightning/imip.css that fixes the rwapping problem Ian Malone mentioned. Thanks for the first patch! In the future, please request review from me (or someone I designate), and we'd prefer the unified patch format including the full filename (usually starting with a/calendar/...)

Comment on attachment 551862 [details] [diff] [review] This is a diff for chrome/lightning/skin/lightning/imip.css that fixes the rwapping problem Ian Malone mentioned. Hey Daniel, I finally got around to testing this. While it does fix the wrapping issue, I think we should work on finding the right lengths. 29em is quite narrow if you have the long Google Calendar link in there and there's still enough room on both sides. I'd suggest to give it a max width based on the width of the parent container. If this can't be done with normal css, you could explore the new -moz-calc css stuff to calculate the width. r- for now to make the wrapping less narrow.

Argh sorry, I was just speaking to a Daniel before I commented. Dennis of course!

I've been banging my head against this for quite a while and I decided to read through this bug report again. To summarize: -this has been a problem (albeit very minor) for quite a while. -I have personally spent hours trying to figure out how to make this thing work, while making almost no headway. (It's possibly due to my inexperience and lack of understanding of any C++ code.) -The functionality that is added by the html display of the attached ics is minimal and is not up to the current quality standards of Thunderbird or Lightning. So, what exactly are we gaining by keeping this functionality around? I found that disabling this functionality is easily accomplished by removing lightningTextCalendarConverter.js and lightningTextCalendarConverter.manifest. All of my invites are through gmail, which also shows the invite information in the message body. I don't know about anyone else, but if this functionality sticks around, I'll be removing those two files from lightning until they add some useful functionality.

I consider this a major bug, because it hides any details, including additional information being sent to all guests via Google Calendar's "Email guests" feature (which also attaches the .ics file). Couldn't lightningTextCalendarConverter be made to keep the original mail text/html, and only append the parsed information?

(In reply to Daniel Hahler from comment #18) > Couldn't lightningTextCalendarConverter be made to keep the original mail > text/html, and only append the parsed information? That's precisely what I was looking to do, and after spending quite a bit of time on it, it appears to be impossible. It's been a while since I looked into it, but if I remember correctly, here's the way things go: lightningTextCalendarConverter inspects emails that look like they contain calendar information. If an email matches, it flips some switch in the background that then converts the message from an email to an event. The message body would need to be grabbed before this step, and as I recall, I couldn't figure out how to do that... it seemed like there was no hook in the system for it. Because the converter is not aware of the message body, it can't just tack the event summary below it. Because the message has been converted from an email to an event, the summary is the only thing that is shown (it can't display an email and an event at the same time). For months now, every time lightning updates, I remove those 2 files related to this functionality (lightningTextCalendarConverter.js and lightningTextCalendarConverter.manifest) and everything works fine, and I'm able to see the original email and the attachment and interact with lightning, thunderbird and my calendar seamlessly. To sum up: - If it is decided that lightning should keep the functionality, lightningTextCalendarConverter needs to be extended (most likely entirely reworked). This will allow it to either get the message body, or not clobber the message with its functionality. It may be the case that it was originally designed to do this, but the way thunderbird handles the situation changed, and the converter was never updated to work properly. - Removing the functionality entirely is very easy to do, and since we're not gaining anything useful from it currently, it seems like it should be removed at least until such time as it provides useful functionality.

Actually the message body is preserved because if you hit a reply button it will get quoted. For now this is my work around to see what the invitee wrote. Could somebody please fix this?

Where is the code that manipulates the message display? I might take a look, according to bug 1360155 comment #18 it might not be too had to fix. Since I've done a bit of work in mailnews MIME, I've come across this snippet: https://dxr.mozilla.org/comm-central/rev/d2b81af84925c478d9a7c2ef888351e1ba9b5fce/mailnews/mime/src/mimei.cpp#464

The key for this lies in mailnews mime code. Lightning itself gets already fed with only the ics, which then is processed in calendar/lightning/components/lightningTextCalendarConverter.js - the mime code handing the content to Lightning is ancient and was written long before I joined the project, so if you already touched mimje code, you might have a better grasp then me. As a first step, you probably might want to find out why text is displayed in the scenario described in bug 1360155 comment #18 and see where you get from there. However, even if the fix would turn to be easy, such a change would require a thoroughly and extensively testing with a good set of MUAs to make sure to not break interoperability, namely _all_ versions of OL and major webmail services. I'm not sure, but I think the current behaviour was implemented to assure interoperability with certain versions of OL.

Thanks for the pointer, I've briefly looked at this and found https://dxr.mozilla.org/comm-central/rev/7b75c2e0b9deb590c18aaddb2a6168146cde8ca4/mailnews/mime/src/nsSimpleMimeConverterStub.cpp#99 nsresult rv = ssobj->innerScriptable->ConvertToHTML(nsDependentCString(obj->content_type), *ssobj->buffer, asHTML); which is where MIME calls into the add-on to convert the text/calendar part into HTML for display. That's understandable. What isn't so understandable is that the message display depends on whether the invitation was accepted or not. Even if that interface returned garbage, that shouldn't affect the HTML display of the message. I noticed this: When the invitation is not accepted the URL shown in the message window is, for example: mailbox:///D:/MAIL-THUNDERBIRD/jorgk.default/Mail/jorgk.jorgk.com/Trash?number=30 With the invitation accepted, that changes to a long data URL: data:text/html;base64,PGh0bWw+PGhlYWQ+PG1ldGEga... which (when decoded) shows the HTML for the invitation. So someone feels the urge to replace the URL viewed with the HTML from the invitation. I don't understand your comment #25: What interoperability are you talking about? All I want to do is not to hide the original message when the event is accepted. What does that have to do with MUA, OL, web services, etc.? Is seems to be purely a MIME problem in TB. No one wants to change the message make-up.

Actually, what happens when you add the event, the imipAddButton? Does that in any shape of form communicate back to MIME? I wouldn't think so it should just refresh the notification bar, right? Or maybe it also refreshes the message display at which stage MIME messes up. If you look closely, after accepting the invitation, the original message HTML is still there for a split second, it's then replaced with the HTML of the event. However, when revisiting the message where the event was accepted, only the event is shows. So somehow the fact that the event was accepted must come back to MIME. Weird.

Hmm, there is a lot more messing around with the message window, for example a the end of lightningTextCalendarConverter.js, then in imip-bar.js where it observes onItipItemCreation and also in calItipUtils.jsm where it reaches into the message. I haven't seen any spot there it would reach into the message body though. It would be good to know how it all hangs together instead of reverse-engineering it :-( Oh, found something else interesting: https://dxr.mozilla.org/comm-central/rev/7b75c2e0b9deb590c18aaddb2a6168146cde8ca4/calendar/lightning/content/imip-bar.js#277 msgWindow.displayHTMLInMessagePane("", msgOverlay, false); Looks like this is killing the message display for some reason.

Removing this line fixes the problem for me. I don't see why nuking the message display is a good idea when the event item is updated. If removing it is not an option, maybe some sort of refresh call would be good. So perhaps someone can shed some light onto why this line was there in the first place, I don't think we can blame Mr. E.S. Lint here, which is what the history shows me. Looking at https://hg.mozilla.org/comm-central/rev/2aa2ae33bf0a#l1.75 I equally can't blame MakeMyDay since that line predates his changes.

Try run here: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=7449542d0797d6a07e75a37c7173e2872c71c689 I know Xpcshell is not affected by this, but I needed that for another bug.

Green try.

Comment on attachment 8898455 [details] [diff] [review] 388584-message-gone-after-accept.patch Thanks for looking into this. Unfortunately, I don't see any difference when viewing the example email from this bug with or without your patch applied. If you have an email example, where this has any effect, please attach it to the bug. In this case, please also describe which view options you are using (orginal html/simple html/plain text; displayAttachmentsInline on/off) to do so. While checking with different resevations I have from e.g. airlines, car rental or others in my inbox, I noticed that current Daily doesn't recognize the calendar part anymore, while ESR52 still does. So the mime changes since 52 seem to have some regressions (As I haven't looked into detail for now, I'm not saying that they are faulty, but the handling seems to be at least less gracefully). But i will file a separate bug for that the other day.

Comment on attachment 8898455 [details] [diff] [review] 388584-message-gone-after-accept.patch Sadly the sample e-mail here is completely nonsensical since it doesn't even contain a part that could be hidden. I'll forward you a real test case in a PM.

Oh actually, there is a usable test cases in a duplicate, bug 1360155, attachment 8862506 [details]. Note that the body "Text." disappears when accepting the invitation. The patch fixes that.

Or maybe I'm on the wrong party here. I essentially wanted to fix bug 1360155 which you referred here as a duplicate. So feel free to approve this as fix for bug 1360155 and I'll get the hell out of here.

Comment on attachment 276098 [details] offending google calendar event update email My apologies, the test case contains a body, I didn't spot it when I looked at it in a hurry. The body doesn't show regardless of whether the event is accepted or not. I'm in the wrong bug here. The bug I want to fix is that the body disappears once the invitation is accepted and reappears when the event is deleted. That's bug 1360155 which was erroneously duped here.

OK, I've finally looked at it in detail. The MIME structure of the message is: multipart/mixed multipart/alternative text/plain text/html text/calendar text/calendar attachment. In other words, the is a calendar event as the last part of a multipart/alternative. That part is displayed, and nothing else, that's the definition of multipart/alternative according to RFC 1341: https://www.ietf.org/rfc/rfc1341.txt ... Receiving user agents should pick and display the last format they are capable of displaying. In the case where one of the alternatives is itself of type "multipart" and contains unrecognized sub-parts, the user agent may choose either to show that alternative, an earlier alternative, or both. TB shows one alternative part only, and it's the last one it can interpret which is the calendar part. This bug is invalid.

BTW, I reopened the alleged duplicates of this bug, bug 955663 and bug 843993 to see whether there are any *valid* examples that don't work.