right now, it does nothing.
Status: NEW → ASSIGNED
Target Milestone: M10
accepting, marking m10
reassigning to sspitzer.
Status: NEW → ASSIGNED
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
moving to m16.
Target Milestone: M15 → M16
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.
Mail Triage is marking [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?
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.email@example.com 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..
> 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:firstname.lastname@example.org (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.
I would nominate for Mozilla 1.3, but a keyword for that release does not exist.
*** 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. ***
*** 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. ***
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
Requesting 1.3b blocking, see previous comment. pi
-> 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.
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:email@example.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
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
> 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.
> > 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.)
Nominating for the reason given in comment 53. pi
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
We're not likely to hold 1.7 alpha for this enhancement.
Severity: major → enhancement
Flags: blocking1.7a? → blocking1.7a-
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
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
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. 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.
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
(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.
*** Bug 287928 has been marked as a duplicate of this bug. ***
*** Bug 287928 has been marked as a duplicate of this bug. ***
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
13 years ago
Duplicate of this bug: 353077
Filter on "Nobody_NScomTLD_20080620"
QA Contact: stephend → backend
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.)
You need to log in before you can comment on or make changes to this bug.