Last Comment Bug 403768 - [calendar integration] invitation bar does not show when "View -> Display Attachments inline" is unchecked
: [calendar integration] invitation bar does not show when "View -> Display Att...
Status: NEW
:
Product: Calendar
Classification: Client Software
Component: E-mail based Scheduling (iTIP/iMIP) (show other bugs)
: unspecified
: All All
: -- normal with 8 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 438866 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-14 06:33 PST by Przemyslaw Bialik
Modified: 2014-11-24 00:59 PST (History)
13 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Przemyslaw Bialik 2007-11-14 06:33:43 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.10pre) Gecko/20071114 Thunderbird/2.0.0.10pre ID:2007111403 + Lightning 0.8pre build 2007111404

Invitation bar does not show on e-mail with invite message when "View -> Display Attachments inline" is unchecked.

Reproducible: Always

Steps to Reproduce:
1. Make sure you have "View -> Display Attachments inline" unchecked
2. Select e-mail with invite message
Actual Results:  
Invitation bar does not show up

Expected Results:  
Invitation bar does show up (as it does with "View -> Display Attachments inline" checked)

Link to this bug can be added to the relnotes (http://www.mozilla.org/projects/calendar/releases/lightning0.7.html)
Comment 1 Mauro Cicognini 2007-11-14 06:46:21 PST
I can confirm this.
Comment 2 Philipp Kewisch [:Fallen] 2007-11-14 07:20:53 PST
Please use the wanted flags to request features and bugfixes for 0.8. The reason is not quite obvious, but I do know why:

If the attachment is not "displayed inline", then the body is not fully loaded, to save processing time and network load. Unfortunately, this does not expose the email as an invitation, therefore the bar is not shown.

Loading the attachments manually will increase processing time immensely for large attachments, regardless of them being an invitation or not.

Comment 3 Simon Paquet [:sipaq] 2007-11-14 07:56:12 PST
Nice to have, but surely not a priority.
Comment 4 Przemyslaw Bialik 2007-11-14 10:09:35 PST
(In reply to comment #2)
> Please use the wanted flags to request features and bugfixes for 0.8.
ok, sorry

> If the attachment is not "displayed inline", then the body is not fully loaded,
> to save processing time and network load. Unfortunately, this does not expose
> the email as an invitation, therefore the bar is not shown.
furthermore because of Bug 357480 (raising priority ?) user can't double click on attachment.ics in order to add it to the calendar so users with this setting do not have an easy way to add invitation to their calendar
 
> Loading the attachments manually will increase processing time immensely for
> large attachments, regardless of them being an invitation or not.
so it would be probably not easy fixing this bug :| 

(In reply to comment #3)
> Nice to have, but surely not a priority.
understood, "luckily" option to have attachments displayed inline is the default setting
What do you think if lightning would default mail.inline_attachments pref to true when being installed (until this bug is not fixed) ?
Comment 5 6e77a 70 6e 6e7a 2008-04-13 18:23:52 PDT
Even worse with Lightning 0.8 + Thunderbird 2.0.0.12. After the upgrade I get no content AND no attachments. When I uncheck "display attachments inline" I can see the attachments, but that does me no good. Time to downgrade to 0.7...
Comment 6 Magnus Melin 2008-04-15 09:47:32 PDT
This bugs make it very confusing to get invites if one doesn't have the "Display Attachments inline" checked. The mail shows completely blank, instead of showing the normal text like it does when lightning isn't installed. (I assume this bug covers that too?)
Comment 7 6e77a 70 6e 6e7a 2008-04-20 11:30:00 PDT
I just noticed someone marked this as blocking calendar 0.9. Why is it not blocking 0.8 when it's worse than 0.7 was? (See Comment #5.)
Comment 8 Stefan Sitter 2008-06-12 10:42:02 PDT
*** Bug 438866 has been marked as a duplicate of this bug. ***
Comment 9 Daniel Boelzle [:dbo] 2008-08-15 05:11:22 PDT
Reading comment #2: Maybe it's an option to auto load text/calendar messages regardless of the attachments setting?
Comment 10 Simon Paquet [:sipaq] 2008-08-15 13:35:50 PDT
I disagree with the tb-integration flag. This is not something that we can fix in our code as far as I remember, as this needs changes in the mailnews core code.
Comment 11 Daniel Boelzle [:dbo] 2008-08-16 10:32:17 PDT
Right, but I don't think tb-integration necessarily means that the bug falls into calendar code; I agree, it makes sense to shift the bug into thunderbird-land. Though it's a common pitfall that should be fixed before tb-integration IMO.
Comment 12 Dan Mosedale (:dmose) 2008-08-25 10:28:15 PDT
I agree with the reasoning in comment 11; marking as tb-integration+.
Comment 13 Philipp Kewisch [:Fallen] 2008-10-15 02:42:41 PDT
Shifting into thunderbird land, we need fixes there before we can take action in calendar code.
Comment 14 Bryan Clark (DevTools PM) [@clarkbw] 2009-01-22 11:00:09 PST
Moving off the tb-blocking bugs.  This would be nice to have, but I don't think we're going to block release if this is not fixed.
Comment 15 Wayne Mery (:wsmwk, NI for questions) 2010-12-29 12:29:48 PST
:fallen
> we need fixes there before we can take action in calendar code.

thus, should this be a tb-wanted?
Comment 16 Mark Banner (:standard8) (afk until 26th July) 2011-02-21 15:30:30 PST
(In reply to comment #13)
> Shifting into thunderbird land, we need fixes there before we can take action
> in calendar code.

:Fallen, what are these fixes? I see no reference to them here, so I can't even work out what would be the way forward with this bug.
Comment 17 Philipp Kewisch [:Fallen] 2011-02-21 23:24:09 PST
I guess there are a few options here. The easiest way to fix this would be to have Lightning force Display Attachments Inline, but this is bad for the user that wants it disabled.

What would be better is a way to have Thunderbird load at least the headers to all attachment parts, at latest when the message is opened. Then Lightning should be able to iterate the attachment parts and needs a way to force loading a specific attachment.
Comment 18 Ludovic Hirlimann [:Usul] 2011-02-21 23:35:26 PST
(In reply to comment #17)

> What would be better is a way to have Thunderbird load at least the headers to
> all attachment parts, at latest when the message is opened. Then Lightning
> should be able to iterate the attachment parts and needs a way to force loading
> a specific attachment.

Did you look how enigmail was doing this ?
Comment 19 Philipp Kewisch [:Fallen] 2011-02-22 00:56:00 PST
(In reply to comment #18)
> Did you look how enigmail was doing this ?

To me it looks like enigmail has an insane amount of code to fix this issue. If I understood things correctly, they use MsgHdrToMimeMessage to stream the message manually and then search the content parts. It would be better for both of us if we could easily retrieve attachments based on their multipart header.
Comment 20 Patrick Brunschwig 2011-02-22 03:08:54 PST
(In reply to comment #19)
> To me it looks like enigmail has an insane amount of code to fix this issue. If
> I understood things correctly, they use MsgHdrToMimeMessage to stream the
> message manually and then search the content parts. It would be better for both
> of us if we could easily retrieve attachments based on their multipart header.

That's quite correct, but don't forget that Enigmail needs to do a few funky things that you hopefully won't need to do :-). Furthermore, Enigmail support 3 different content-types that need very different treating.

But the essence of what Enigmail does is less than 50 lines of code. The basics of the implementation are this:

var msgFrame = EnigmailCommon.getFrame(window, "messagepane"); // iterate through the window.frames to get the one called "messagepane"

if (msgFrame) {
  msgFrame.addEventListener("load", messageProcessingFunction, false);
}

function messageProcessingFunction() {
 process the the MIME tree with MsgHdrToMimeMessage()
}

I'm not 100% sure  that you really need to process the mime tree. If the calendar file is recognized as attachment (i.e. displayed as attachment), then it's sufficient to iterate through the attachments. Thunderbird holds them in a global variable "currentAttachments".
Comment 21 Philipp Kewisch [:Fallen] 2011-02-22 05:56:38 PST
(In reply to comment #20)
> I'm not 100% sure  that you really need to process the mime tree. If the
> calendar file is recognized as attachment (i.e. displayed as attachment), then
> it's sufficient to iterate through the attachments. Thunderbird holds them in a
> global variable "currentAttachments".

We only process real attachments. Are they put in currentAttachments, even if display attachments inline is off?
Comment 22 Patrick Brunschwig 2011-02-22 07:35:35 PST
(In reply to comment #21) 
> 
> We only process real attachments. Are they put in currentAttachments, even if
> display attachments inline is off?

Yes, the array always contains all attachments.
Comment 23 Philipp Kewisch [:Fallen] 2011-02-22 07:39:50 PST
In that case I guess we can take this back to calendar land.
Comment 24 Mark Banner (:standard8) (afk until 26th July) 2011-02-22 12:25:31 PST
Sorry for noise, moving bug back to Thunderbird temporarily so I can clear the blocking-thunderbird3.3 flag (known issue)
Comment 25 Josef Kufner 2014-02-14 09:12:15 PST
Icedove 24.3.0 on Debian Linux and the bug is still there. Exactly the same as described 5 years ago.

Funny is, that clicking the attached invite.ics offers korganizer as default application to handle the event.

Is it possible to let Lightning handle this file and open dialog window containing event preview and missing toolbar? Such file handler would also allow to open files from other programs or received via bluetooth.

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