Open Bug 341059 Opened 18 years ago Updated 2 years ago

MIME messages should be displayed using separate DOM documents for each part

Categories

(MailNews Core :: MIME, defect)

defect

Tracking

(Not tracked)

People

(Reporter: eyalroz1, Unassigned)

References

(Blocks 2 open bugs)

Details

When messages are displayed, different MIME parts are converted into HTML and put within separate DIV's within a DOM document for the entire message. However, this is not always appropriae. For example, they may have a different character set - but you can only set a single charset for them both. Since the charset is often misdetected and has to be corrected ex-post-facto (see the code of the BiDi UI extension for details; see also bug 260728 and maybe some others), there is need to change the charset of individual parts. And it should not be too difficult to come up with other reasons to have each part be a DOM document unto itself.
xref bug 82280.
Bug 76804 might also be resolved by a similar approach.
The question is, do these bugs depend on this one or does this bug constitute an alternative approach to fixing those bugs?
Summary: MIME message parts must be converted into separate XUL documents → MIME message parts should be converted into separate XUL documents
Summary: MIME message parts should be converted into separate XUL documents → MIME messages should be displayed using separate DOM documents for each part
This would also resolve the problem of interfering class/id name spaces for style specification, identified as cause for bug 148742. However, given the discussion in bug 441275 (eventually resolved as dupe for bug 31052), there appears to be some resistance for implementing such a more comprehensive solution.
I think the "resistance" in bug 441275 was a matter of semantics.
There is surely a problem here, but I thought it should be an ENH rather than a bug. The approach here would remove the true meaning of "inline".

Another approach would be to offer View->attachments in tabs.
Either opening all attachments in a separate tab, or at the very least enabling the "right click" dropdown option "Open in a new tab"

This would give us a separate DOM document for each part.

cc to David for insight to a possible tabs solution. 
Product: Core → MailNews Core
Pegasus Mail's message window has a separate tab for attachments. This two pane tab has a attachment list in the top pane and a view pane in the bottom pane.

And there is a "Raw View" tab as well corresponding to our View Source window.
"raw view" and displaying every attach in separate tab are not replacement for inline attachment view.
For example, I receive a letter with some text, 20 pictures, and some more text.
To see it, switching between tabs or windows, and see as one scroll are not equal.
(In reply to comment #6)
> "raw view" and displaying every attach in separate tab are not replacement for
> inline attachment view.
View attachments inline should never be removed IMO
> For example, I receive a letter with some text, 20 pictures, and some more
> text.
Just how is that example composed ? as 3 mime parts? I would suggest if that is the case, then including the images as CID's (inserted into the composition), would be a more appropriate method

While I'm on the topic of CID's I think we should think about more clearly defining the purpose of an attachment (beyond the CID placeholder)
Right now, inserting an image in a message results in Content-Disposition: Attachment; Using the suggestions in RFC 2183 (Content-Disposition: inline; would serve to clarify the intent of the sender.
No, i mean all separate attachements. Plain text message, 20 separate attached pictures (for example, photos from insurance case claim), and one html file attachment with some css inside.

Often I send letters with plain text message, attached html (produced via "send page by email), some more html, added with drag and-drop from other browser tabs or windows.
Often that html attachments makes email as shame, but read every part in different tabs may be only as workaround, because it uncomfortable in case all attachments logically chained, and/or are small enough to place in one page.

Other example - 50-60 icons, buttons, pictograms etc. Simply scroll one long list - or swich via 50-60 tabs?
Igor, your use case is important to the future development of Thunderbird IMO
Generally, Mozilla does not promote the use of html in email. I think this is a mistake, as this it what people want to do.
Is your usage commonplace in your locale ?
Personally, I think html compositions should be just that. That is, a complete, tested composition with all elements included in one main body. But who am I to decide what works for you. Especially since the editor is so buggy.
Thanks for your input.
And for others, sorry for the bugspam.
I an a geek, so not so much of my correspondents send plain text messages. Most of it are html text.
But very, very rarely anybody places picture inside html mail body, if picture is not part of text. Really, it was some exclusive cases. I got screenshots in .bmp format inserted into MS Word doc files more often, then pictures, meaning attaches, inside mail body.

Typical letter with pictures from my not-geek correspondent looks like 
- plain text letter text
- html letter text, maybe, with pictures inside
- some pictures as attachment

rarely I got a plant text attaches - log files, config files, scripts etc.
It can be comfortable to have a possibility to see some of it inside tabs. **can**. Or can not. But it's very uncomfortable, when I can't see in as long scroll. 
I know, what I say about - rarely I receive messages from weird mail clients, declares text files as binary, and I have to open it at other browser windows via "view as text" or similar extension, or save and open in text editor.

So, started claim was not about pictures in attachment, but about html.
There no case to worry about in case of usung composer. 

The case is have more then 1 html document to display, if this document uses some of features: background color, some type of text positioning, maybe, some more hints. displaying it in different DOM docs, placed in one roll of message body, can resolve this problem, and keep comfortable viewing, like today for simplest attached text and html files.
(In reply to comment #7)
>
> While I'm on the topic of CID's I think we should think about more clearly
> defining the purpose of an attachment (beyond the CID placeholder)
> Right now, inserting an image in a message results in Content-Disposition:
> Attachment; Using the suggestions in RFC 2183 (Content-Disposition: inline;
> would serve to clarify the intent of the sender.

We do?  Ugh.  If you could file a separate bug for that, it would be much appreciated, as that's likely to be much easier to fix than the other stuff documented here.
(In reply to comment #7 and comment #11)
Actually, this depends on mail.content_disposition_type, which changed its default to "attachment" per bug 65794. If I set it manually to "0", I get the desired "Content-Disposition: inline;" heading. Thus, this is asking for a special-case handling for such images.
dmose:
There is an excellent summary and suggestions for improvements in bug 452092
rsx11m: I had interpreted "inserting an image in a message" as putting an image in as part of HTML content (e.g. by drag-n-drop), which is where I would consider "inline" to be a bug.  Merely using the "attach" UI is clearly different, I'm not so sure about an exception there.

Joe: Thanks for the pointer to bug 452092; it looks like that covers these issues nicely.
Er, what I _actually_ meant to say was 'where I would consider "attachment" to be a bug.'
I don't see how having separate DOM documents one after another would hurt inline mode so badly. Can someone explain?
More pro's than con's IMO for implementing separate DOM documents.
But, given the "one window" rendering has been around forever, I'm sure someone is stacking up attachments expecting them to interact.
I would look at this from a programmer's perspective, i.e., analogous to scope of declarations. Assuming that the message is a hierarchy of parts (the main message, several attachments, where attachments may in turn contain nested attachments, e.g., for message/rfc822 parts, etc.), a style declaration from a higher-level part may be inherited from a lower-level part (e.g., background and font color), but definitions of a lower-level part should not leak into neighboring or higher levels and should be restricted to their scopes. I'm not sure if this is the intention of any RFC standardizing multi-part messages, but it appears to be the most intuitive way to look at this.

In terms of implementation, approximating it by separating the scopes of each part completely in their own self-contained DOM is in my opinion still better than the rather uncontrolled (and frequently unexpected/unintended) leaking of styles to other parts we have now. I could also imagine a configuration option to make everybody happy.
> higher-level part may be inherited from a lower-level part (e.g., background
s/from/by/ (oops...)
See also bug 183726 resolved EXPIRED in 2005 (and which should IMO be moved to Mailnews Core if reopened)
Blocks: 148742
Something like this bug 341059 or bug 82280 (or bug 183726) would fix a lot of multipart message display problems currently collected in Bug 31052 (currently 14 dupes, 11 votes).
Blocks: 31052
See Also: → 82280
(In reply to Thomas D. from comment #22)
> Something like this bug 341059 or bug 82280 (or bug 183726) would fix a lot
> of multipart message display problems currently collected in Bug 31052
> (currently 14 dupes, 11 votes).

Jorg, do I remember correctly you commented in the last week about displying message parts from separate dom objects?  (I know someone did)
Flags: needinfo?(jorgk)
Yes, if I had time I'd look further into bug 1297653 which was a duplicate of bug 31052. All these bugs basically describe the same issue: All message parts are displayed in the same document which caused "cross disturbance" of various kinds. This problem is as old as Thunderbird, oh, sorry, Netscape :-(
Flags: needinfo?(jorgk)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.