Open Bug 11076 Opened 25 years ago Updated 2 months ago

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

Categories

(MailNews Core :: Backend, enhancement, P3)

Product:
MailNews Core
Component:
Backend
Type:
enhancement

Tracking

(Not tracked)

Milestone:
Future

People

(Reporter: sspitzer, Unassigned)

References

(Blocks 2 open bugs,
URL
)

Details

(Keywords: testcase, Whiteboard: See comment 53 for summary)

Attachments

(1 file, 1 obsolete file)

Test message, m/r with HTML
2.13 KB, message/rfc822
Details 
right now, it does nothing.
Status: NEW → ASSIGNED
Target Milestone: M10
accepting, marking m10
Assignee: phil → sspitzer
Status: ASSIGNED → NEW
reassigning to sspitzer.
Status: NEW → ASSIGNED
accepting bug.
Target Milestone: M10 → M11
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?
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.
Triage to M15
QA Contact: lchiang → huang
moving to m16.
Target Milestone: M15 → M16
Depends on: 30355
Is this still a bug?
Mass moving M16 to M17 - look for nsbeta2 before anything else.
Target Milestone: M16 → M17
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.
Summary: news://host/article should open the article in a new browser window. → news://host/article should open the article in a new browser window
Is this the case for all messages or just news messages?
*** Bug 46219 has been marked as a duplicate of this bug. ***
Nominate this should work on nsbeta3 -- adding nsbeta3 for the keywords.
Keywords: nsbeta3
Mail Triage is marking [nsbeta3-]
Whiteboard: [nsbeta3-]
Target Milestone: M17 → Future
Summary: news://host/article should open the article in a new browser window → news://host/article or imap:// should open the article/mail in a new mail window
This is also for imap://
mass change of huang's news bugs to stephend.
QA Contact: huang → stephend
*** Bug 68152 has been marked as a duplicate of this bug. ***
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?
URL: news://host/article
don't file that, at the very least someone filed it as bug 99710.
(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/3BCD1FE7.60208@meer.net is a current link on 
the mozilla.org front page under Mozilla 1.0 manifesto - news.
adding *.eml.

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

that might be covered in other bugs, not sure.
Summary: news://host/article or imap:// should open the article/mail in a new mail window → *.eml, news://host/article or imap:// should open the article/mail in a new mail window
Bug 34150 is an alternative implementation.
*** Bug 117789 has been marked as a duplicate of this bug. ***
*** Bug 118099 has been marked as a duplicate of this bug. ***
*** Bug 118100 has been marked as a duplicate of this bug. ***
*** Bug 109323 has been marked as a duplicate of this bug. ***
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.
*** Bug 135276 has been marked as a duplicate of this bug. ***
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.
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..
Whiteboard: [nsbeta3-]
> 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.
Maybe your mimetype was wrong?
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.
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?
> 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.
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$3@news.t-online.com (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
*** Bug 145865 has been marked as a duplicate of this bug. ***
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.
Blocks: 26201
I would nominate for Mozilla 1.3, but a keyword for that release does not exist.
Keywords: mozilla1.2, nsbeta1
*** Bug 169866 has been marked as a duplicate of this bug. ***
*** Bug 170280 has been marked as a duplicate of this bug. ***
*** Bug 171907 has been marked as a duplicate of this bug. ***
*** Bug 174548 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.3
*** Bug 178107 has been marked as a duplicate of this bug. ***
Part1.2 is often used to name forwarded email.

JG 
*** Bug 176720 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.2
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
Severity: normal → major
No longer depends on: 30355
Keywords: nsbeta1 → nsbeta1-
Requesting 1.3b blocking, see previous comment.

pi
Flags: blocking1.3b?
Flags: blocking1.3b? → blocking1.3b-
-> 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.
Severity: major → enhancement
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.
Severity: enhancement → normal
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
Severity: normal → major
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.
Depends on: 160141
No longer depends on: 160141
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$3@news.t-online.com (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
Flags: blocking1.4b?
Keywords: mozilla1.3 → testcase
Flags: blocking1.4b? → blocking1.4b-
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. 
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
Blocks: 108877
> 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.
Flags: blocking1.4?
> > 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?
Summary: *.eml, news://host/article or imap:// should open the article/mail in a new mail window → *.eml, news://host/article or imap:// should open the article/mail in a (new?) mail window
Yes - but in the browser window you have a back button and in the mailnews
window not.
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.
> 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.
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.)
Flags: blocking1.4? → blocking1.4-
Nominating for the reason given in comment 53.

pi
Flags: blocking1.5?
Flags: blocking1.5? → blocking1.5-
Any progress on this?
I need support for .eml files ASAP!
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.
*** Bug 229472 has been marked as a duplicate of this bug. ***
This bug blocks a lot of functionality for MailNews (see comment 53). Asking for
blocking.

pi
Flags: blocking1.7a?
We're not likely to hold 1.7 alpha for this enhancement.
Severity: major → enhancement
Flags: blocking1.7a? → blocking1.7a-
Depends on: 236637
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
Flags: blocking1.8a?
Whiteboard: See comment 53 for summary
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
Flags: blocking1.8a?
Flags: blocking1.8a-
Flags: blocking1.5-
Flags: blocking1.4b-
Flags: blocking1.4-
Flags: blocking1.3b-
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
As per comment 54, bug 89939 and bug 108877 block this bug.
No longer blocks: 108877
Depends on: 89939, 108877
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.
No longer depends on: 89939, 108877, 236637
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
Blocks: 108877
(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?
> what about making this filename ... a link to open/save the attached item?

Good idea, filed bug 264167 about it.
Product: MailNews → Core
Blocks: 269826
No longer depends on: 269826
*** Bug 287928 has been marked as a duplicate of this bug. ***
*** Bug 287928 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
No longer blocks: majorbugs
sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Status: ASSIGNED → NEW
Filter on "Nobody_NScomTLD_20080620"
QA Contact: stephend → backend
Product: Core → MailNews Core
I think we now have tabs as well.
After 12 years one of the most basics function of a newsreader don't work?!

Also relates to bug 108877.

pi
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.)
See Also: → 745856
Severity: normal → S3
Attachment #9386995 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: