11076 - *.eml, news://host/article or imap:// should open the article/mail in a (new?) mail window

Status: NEW

(MailNews Core :: Backend, enhancement, P3)

Description

[(not reading, please use [e-mail] instead)]

right now, it does nothing.

Comment 1

[(not reading, please use [e-mail] instead)]

accepting, marking m10

Comment 2

[scottputterman]

reassigning to sspitzer.

Comment 3

[(not reading, please use [e-mail] instead)]

accepting bug.

Comment 4

[(not reading, please use [e-mail] instead)]

moving to m11.  I won't have time to do this for m10.

alecf / mscott:  is there a similar bug for having a IMAP (or pop url) for a
message doing the same thing?

Comment 5

[Scott MacGregor]

Yeah there are a bunch of bugs floating around for these.

We're still in the design phase of url dispatching to new windows...we'll be
lucky to hit it by M11 but we'll see. See the discussion in the netlib newsgroup
to see where we are at for more details.

Comment 6

[Phil Peterson]

Triage to M15

Comment 7

[(not reading, please use [e-mail] instead)]

moving to m16.

Comment 8

[selmer (gone)]

Is this still a bug?

Comment 9

[selmer (gone)]

Mass moving M16 to M17 - look for nsbeta2 before anything else.

Comment 10

[laurel]

I'm confused as to what's correct... if I base this on 4.x behavior, I see a
followed news article link open in a (new) standalone message window when
following from a browser.  It doesn't open in a browser window.  Don't know
what's right here. I would opt for a new standalone message window.

Comment 11

[scottputterman]

Is this the case for all messages or just news messages?

Comment 12

[lchiang]

*** Bug 46219 has been marked as a duplicate of this bug. ***

Comment 13

[Karen Huang]

Nominate this should work on nsbeta3 -- adding nsbeta3 for the keywords.

Comment 14

[scottputterman]

Mail Triage is marking [nsbeta3-]

Comment 15

[Henrik Gemal]

This is also for imap://

Comment 16

[laurel]

mass change of huang's news bugs to stephend.

Comment 17

[[e-mail] (gone - use [e-mail] instead)]

*** Bug 68152 has been marked as a duplicate of this bug. ***

Comment 18

[jlarsen]

Also, when right clicking on news://  open new window is not an option. Even if
it is decided that a new window isn't automatically opened, I should have such
an option. Should I file this as a new bug?

Comment 19

[timeless]

don't file that, at the very least someone filed it as bug 99710.

Comment 20

[Luke Morey]

(moved this comment from bug 72969)

Is this right?  news://server/article@article opens in a browser window, not 
mailnews.

e.g. news://news.mozilla.org:119/[e-mail] is a current link on 
the mozilla.org front page under Mozilla 1.0 manifesto - news.

Comment 21

[(not reading, please use [e-mail] instead)]

adding *.eml.

that should open in a std alone msg window, too.

that might be covered in other bugs, not sure.

Comment 22

[Ben Bucksch (:BenB)]

Bug 34150 is an alternative implementation.

Comment 23

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 117789 has been marked as a duplicate of this bug. ***

Comment 24

[Boris Zbarsky [:bzbarsky]]

*** Bug 118099 has been marked as a duplicate of this bug. ***

Comment 25

[Boris Zbarsky [:bzbarsky]]

*** Bug 118100 has been marked as a duplicate of this bug. ***

Comment 26

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 109323 has been marked as a duplicate of this bug. ***

Comment 27

[[not reading bugmail]]

is this possible to get this in for nsbeta1, or mozilla1.0?   I notice clicking
on filename.eml file opens in OE as in bug 26201, but if that is fixed first, it
appears mozilla is not registering that as a Mozilla file. It should open in the
Ctrl+M - open message window, not the browser window.. as OE does.  This is now
going start impacting people more that Mail/News is starting to shape up.

Comment 28

[David :Bienvenu]

*** Bug 135276 has been marked as a duplicate of this bug. ***

Comment 29

[Joel Nelson (don't send email)]

This could be a problem when opening HTML .eml attachments.   The plain text
source is all that is shown when the .eml attachment is displayed in Navigator.

Comment 30

[[not reading bugmail]]

unless you have saved them as plaintext, they should be html..  the way I have
them saved is by using Mail/News do File -> Save As > File .. and it comes up
message.eml which saves it as html.  I could only see this if you change it to
text document or something before saving message.txt as .eml.


-> removing status whiteboard as its from 2000-08-01.. 

Comment 31

[Ben Bucksch (:BenB)]

> This could be a problem when opening HTML .eml attachments. The plain text
> source is all that is shown when the .eml attachment is displayed in Navigator.

WFM. I see the message passing through libmime code and being displayed in
Navigator as in the message viewer, with headers like those of attached mails.
Note: This does not that this bug is fixed, because there is no UI for reply etc..

> message.eml which saves it as html

.eml (select that in the format dropdown) is the raw message, not an HTML
version of it, and SaveAsFile|.eml WFM.

Comment 32

[Ben Bucksch (:BenB)]

Attachment: Test message, m/r with HTML

Maybe your mimetype was wrong?

Comment 33

[[not reading bugmail]]

ben, well it looks like HTML is my point, its not plaintext, and it has headers
etx, like you are saying.   So that is not the problem and we agree that that is
what we see displayed as .eml comes up in a navigator window.  And yes, this bug
is not yet fixed, its about using the message window when you open them up, not
a navigator window to display them.  Anyway, I that is what I was saying.. and
just repeating what you noted.  So we agree we are seeing/talking about the same
exact thing.

Comment 34

[Malcolm Scott]

I was about to fill out a bug saying that some .eml files were rendered by the
browser as in Mozilla Mail, and some were just displayed as the text of the
message source. Then I noticed the comment about mime types above. It seems that
web servers that report *.eml as text/plain (i.e. most of them) get messages
displayed as source; the reason the attachment to this bug works is because the
message has been given mime type "message/rfc822".

For an example of a .eml file being displayed as text: see
http://www.one-newhouses.com/message.eml

Maybe Mozilla should notice by the extension that this is a mail message and not
plain text as reported by the server? Or is this bad?

Comment 35

[Ben Bucksch (:BenB)]

> Or is this bad?

Yes, mimetype-munging is considered harmful. For example, a server admin might
intentionally have sat the mimetype to plaintext to cuase the msg to be
displayed as source.
Fix the server.

Comment 36

[Boris 'pi' Piwinger]

I see two problems with this bug:

1) The message (as it is now) is not displayed correctly, i.e., the coding of an
article is not followed. E.g., in
news://news.cis.dfn.de:119/aabb7p$jo2$06$[e-mail] (replace the server
to one you can access) the name Sören is coded correctly, but Sören is displayed.

2) You cannot answer (reply or follow-up) to that article, even if you have
subscribed to that group on that server.

pi

Comment 37

[R.K.Aa.]

*** Bug 145865 has been marked as a duplicate of this bug. ***

Comment 38

[David Tenser [:djst]]

If a .eml file contains the line "X-Unsent: 1", a compose window should appear
(Ctrl+M), if it doesn't a standard mail window should appear.

It should *never* appear in a browser window.

Comment 39

[Andrew Hagen]

I would nominate for Mozilla 1.3, but a keyword for that release does not exist.

Comment 40

[Matthias Versen [:Matti]]

*** Bug 169866 has been marked as a duplicate of this bug. ***

Comment 41

[Matthias Versen [:Matti]]

*** Bug 170280 has been marked as a duplicate of this bug. ***

Comment 42

[Matthias Versen [:Matti]]

*** Bug 171907 has been marked as a duplicate of this bug. ***

Comment 43

[grylchan]

*** Bug 174548 has been marked as a duplicate of this bug. ***

Comment 44

[Matthias Versen [:Matti]]

*** Bug 178107 has been marked as a duplicate of this bug. ***

Comment 45

[u32858]

Part1.2 is often used to name forwarded email.

JG 

Comment 46

[Matthias Versen [:Matti]]

*** Bug 176720 has been marked as a duplicate of this bug. ***

Comment 47

[Boris 'pi' Piwinger]

Is there any progress for this bug?

Based on my comment 36, I set this to major. I also think much more is blocked
by this bug, actually all those bug which require going to another message (like
clickable references).

Bug 30355 blocked this bug, but was duped onto bug 22889 which is fixed.
Removing dependency.

pi

Comment 48

[Boris 'pi' Piwinger]

Requesting 1.3b blocking, see previous comment.

pi

Comment 49

[Ben Bucksch (:BenB)]

-> enh
This is not a bug. Message opens pretty-formatted in the browser window (if you
enter the URL in the browser urlbar). This is what I would expect, simiar to
what happens with plaintext files (actually, they are not even
pretty-formatted). Thus enhancement.

Comment 50

[Ere Maijala (slow)]

I disagree. Sure, it displays fine, but in the browser you can't do message
tasks, such as filing it to a folder or replying to it. 

Comment 51

[Boris 'pi' Piwinger]

Ben, Ere,

please see my comment 36 and comment 47. Not only is the display broken in the
browser, it does not -- as Ere says -- enable any action on it and it blocks
other bugs which provide basic newsreader features.

pi

Comment 52

[Stefan A. Möller]

And there's another problem: Open a *.eml message with attachment. Only the
message body appears. You don't even see that an attachment exists.

Comment 53

[Boris 'pi' Piwinger]

Let me again list all the problems why this is a must-fix and hence blocking is
requested:

1) The message (as it is now) is not displayed correctly, i.e., the coding of an
article is not followed. E.g., in
news://news.cis.dfn.de:119/aabb7p$jo2$06$[e-mail] (replace the server
to one you can access) the name Sören is coded correctly, but Sören is displayed.

2) You cannot answer (reply or follow-up) to that article, even if you have
subscribed to that group on that server.

3) Major advancements are blocked by this. We will not be able to follow a
news/nntp-URI if we open it in a browser etc.

4) You cannot access attachments, you don't even see them.

pi

Comment 54

[phil]

Note 1: this probably depends on bug 89939 which depends on bug 108877
Note 2: comment #53 is absolutely right.
Note 3: news://server/message-id is not RFC correct apparently according to bug
89939, comment 12

Why must a NEW window be openned? I mean if there is already a 3 pane message
window openned and the URI (whatever the recognised syntax) is entered in the
browser's address bar, why not using the 3 pane window already available? This
is explained in bug 129574 (for a slightly different scenario)

3-pane window
-------------
|   |   T   |   F: Folder pane
|   |       |   T: Thread pane
| F |-------|   M: Message pane
|   |   M   |
|___|_______|

Also, after processing the link, the corresponding "local folder" or server
where the message is should be selected in the folder pane, the message title
visible in the thread pane and the message itself openned in the message pane. 

Comment 55

[Boris 'pi' Piwinger]

Phil, per your last comment:

The dependency might in a way (but I don't think strictly) be the other way
round. Actually, bug 108877 requires to us MailNews, so I'll add it.

I agree to your note 2;-)

Note 3 is certainly formally correct, but is so widely used (way more than the
correct nntp form) that it must be supported.

Well, new window or not might be an option. The advantage of a new window is not
to lose the previous position. There is no such thing as a back button in
Mailnews (would be useful, though).

pi

Comment 56

[Ben Bucksch (:BenB)]

> if [...] the URI (whatever the recognised syntax) is entered in the
> address bar, why not using the 3 pane window already available?

Because it would be quite confusing for users, if they do something in one
window and something in another, existing window happens.

Comment 57

[Aleksey Nogin]

> > if [...] the URI (whatever the recognised syntax) is entered in the
> > address bar, why not using the 3 pane window already available?
>
> Because it would be quite confusing for users, if they do something in one
> window and something in another, existing window happens.

But this is already how it is implemented when you click an http:// URL in a
mail window - it just uses and existing browser window. It is not very confusing
and IMHO a right thing. Why would doing the exactly symmetrical thing (clicking
on a mail URL is browser window uses an existing mail window) be wrong? 

Comment 58

[Daniel Küstner]

Yes - but in the browser window you have a back button and in the mailnews
window not.

Comment 59

[Aleksander Adamowski]

I'd like to support Daniel's and Ben's opinion. It should be opened in a new
window, besides, this is similar to the behaviour of Windows Explorer - .eml
files are opened in new windows.

Comment 60

[Vaclav Dvorak]

> if [...] the URI (whatever the recognised syntax) is entered in the
> address bar, why not using the 3 pane window already available?

Most of all, because the 3 pane window displays context for the message: when a
message is displayed, you can see in which folder it is by looking in the left
pane, and what other messages are in that folder by looking in the upper pane.
But when you enter a URI, you're displaying a message that may not be in any of
your folders. It would be very confusing to see a message in the 3-pane window
without it being placed in one of the folders in the left pane. It should be
displayed in a separate window, just as when you double-click a message in the
3-pane window.

Comment 61

[Mike Cowperthwaite]

I don't know if this is old news; I don't see a reference to it earlier in the 
thread.  In Moz1.3, if you have an email with another email attached, opening 
that attachment puts the full text (including headers) into a browser window.

In 1.4b (at least, in the 0430 build I'm looking at) the attachment opens in a 
message window, with a header pane and a toolbar.  (This window is a little 
glitchy, see Bug 204350.)

Comment 62

[Boris 'pi' Piwinger]

Nominating for the reason given in comment 53.

pi

Comment 63

[Toomas Kask]

Any progress on this?
I need support for .eml files ASAP!

Comment 64

[Prognathous]

Searching the web, I couldn't find any reasonable workaround for this one. The
only thing that works for me is to save the file in OE local folders, then
import it from Mozilla.

Prog.

Comment 65

[Mike Cowperthwaite]

*** Bug 229472 has been marked as a duplicate of this bug. ***

Comment 66

[Boris 'pi' Piwinger]

This bug blocks a lot of functionality for MailNews (see comment 53). Asking for
blocking.

pi

Comment 67

[Asa Dotzler [:asa]]

We're not likely to hold 1.7 alpha for this enhancement. 

Comment 68

[Boris 'pi' Piwinger]

Looks like the next important release will still not have basic newsreader
functionality. So again I ask for blocking.

The problems due to this bug are listed in comment 53.

pi

Comment 69

[Boris 'pi' Piwinger]

Now that bug 236637 which was blocking this was declared invalid by means of fix
of bug 239555, how are chances to get this issue solved?

I really think this bug is causing the most severe limitation in MailNews.

pi

Comment 70

[Boris 'pi' Piwinger]

So what is the policy on this bug? The most simple features of any newsreader
are not available after years of Mozilla development. Every Netscpae version I
remember (I guess from 1.2) was able to display references from postings. Or you
were able to retrieve messages from messages-ids. 

pi

Comment 71

[Andrew Hagen]

As per comment 54, bug 89939 and bug 108877 block this bug.

Comment 72

[Ben Bucksch (:BenB)]

No. They are about supporting news:msg-id URLs, but news:server/msg-id URLs (and
imap: URLs) work already. So, not needed to implement this bug, so no blocker,
just vagely related.

Comment 73

[Boris 'pi' Piwinger]

We block bub 108877, for to support news-URIs in a meaningful way we need to be
able to open this in a mailnews window. Else all the functionality is not
available. See comment 53.

pi

Comment 74

[Alfa]

(In reply to comment #21)
> adding *.eml.
> 
> that should open in a std alone msg window, too.
> 
> that might be covered in other bugs, not sure.

I agree, it's very important to open .eml saved emails.
by now, in 1.7.2 mozilla, you can open it in a browser window to see a .eml file.

the only "little" thing wrong is: attachments are displayed as "tables" with the
filename written inside.
right?
well... what about making this filename text like a link to open/save the
attached item?

just as temporary workaround fix while "open in a standalone message window" bug
is not fixed.
wrong?

Comment 75

[Ben Bucksch (:BenB)]

> what about making this filename ... a link to open/save the attached item?

Good idea, filed bug 264167 about it.

Comment 76

[Patrick]

*** Bug 287928 has been marked as a duplicate of this bug. ***

Comment 77

[Patrick]

*** Bug 287928 has been marked as a duplicate of this bug. ***

Comment 78

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 80

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 81

[klonos]

I think we now have tabs as well.

Comment 82

[Boris 'pi' Piwinger]

After 12 years one of the most basics function of a newsreader don't work?!

Also relates to bug 108877.

pi

Comment 83

[Ben Bucksch (:BenB)]

pi, you had 12 years to learn programming and Mozilla code and you *still* didn't fix it?!??? I'm shocked and disappointed. It's about time. I am expecting a patch from you in the next 6-12 months. That's enough time to learn. (Attention: Joke.)