Closed Bug 239555 Opened 20 years ago Closed 20 years ago

Port ability to open .eml files, and rearrange menu appropriately

Categories

(SeaMonkey :: MailNews: Message Display, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.8alpha3

People

(Reporter: raccettura, Assigned: raccettura)

References

Details

Attachments

(2 files, 1 obsolete file)

This is a port of bug 217149.

SeaMonkey can view .eml files in the browser, but there is no easy mechanism
from within mailnews to open and view them in a mail window.  This patch will
address this shortcoming.

It will suffer the limitations that thunderbird has (see bug 217149 for
details), until we can implement:
http://bugzilla.mozilla.org/show_bug.cgi?id=236637#c2


I'm targeting this at 1.8a, and will most likely have a patch a few days after
the trunk opens up again after the 1.7branch.  Can't make 1.7 without driver
approval because of some string changes.
Status: NEW → ASSIGNED
Attached patch Patch v1 (obsolete) — Splinter Review
First stab/polk at SeaMonkey
Attachment #146034 - Flags: review?(bienvenu)
Comment on attachment 146034 [details] [diff] [review]
Patch v1

looks ok, I'll apply the patch and try it.
Attachment #146034 - Flags: review?(bienvenu) → review+
Comment on attachment 146034 [details] [diff] [review]
Patch v1

spoke too soon:

+	 accesskey="&openMessageFileMenuitem.accesskey;"

this wants to be openMessageFileCmd.accessKey

and the file open dialog doesn't show the .eml files I have in the directory
when I bring it up - don't know why that is...
Attachment #146034 - Flags: review+ → review-
this is Robert's fix, with a couple tweaks, one of which Robert came up with
(the ; separator)
Attachment #146034 - Attachment is obsolete: true
Comment on attachment 146146 [details] [diff] [review]
proposed fix
[Checked in: Comment 7]

r=bienvenu
Attachment #146146 - Flags: superreview?(mscott)
Attachment #146146 - Flags: review+
Attachment #146146 - Flags: superreview?(mscott) → superreview+
requesting checkin along with corresponding MSG patch in bug 217149.
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment on attachment 146146 [details] [diff] [review]
proposed fix
[Checked in: Comment 7]

>+  var ioService = Components.classes["@mozilla.org/network/io-service;1"]
>+                         .getService(Components.interfaces.nsIIOService);
>+  var handler = ioService.getProtocolHandler("file");
>+  var fileHandler = handler.QueryInterface(Components.interfaces.nsIFileProtocolHandler);
>+
>+  var fileUrl = fileHandler.getURLSpecFromFile(fp.file);
>+  var uri = Components.classes["@mozilla.org/network/standard-url;1"].
>+              createInstance(Components.interfaces.nsIURI);
>+  fileUrl += "?type=x-message-display";
>+  uri.spec = fileUrl;
Sigh, all of this code is just so wrong...
Ok, so this fixes the following issues
* Open Message <command> not moved to message menu <commandset>
* JS strict warnings in MsgOpenFromFile
* Really lame file picker to url conversion
* No ellipsis on Open File...
* Duplicate (*.eml; *.msg) on Linux filepicker
If you feel that the Win32 filepicker should display
Mail Files (*.eml; *.msg)
then you need to file a bug on the Win32 filepicker.
Attachment #146177 - Flags: superreview?(bienvenu)
Attachment #146177 - Flags: review?(mscott)
Comment on attachment 146177 [details] [diff] [review]
Cleanup
[Checked in: Comment 28]

thanks for cleaning this up Neil! I don't understand why you made this change
though:

 # LOCALIZATION NOTES(EMLFiles): Do not translate "*.eml, *.msg" in the line
below
-EMLFiles=Mail Files (*.eml, *.msg)
+EMLFiles=Mail Files

Why did you take out the file extension stuff?
(In reply to comment #10)
> (From update of attachment 146177 [details] [diff] [review])
> thanks for cleaning this up Neil! I don't understand why you made this change
> though:
> 
>  # LOCALIZATION NOTES(EMLFiles): Do not translate "*.eml, *.msg" in the line
> below
> -EMLFiles=Mail Files (*.eml, *.msg)
> +EMLFiles=Mail Files
> 
> Why did you take out the file extension stuff?
> 

I believe this is to address:
>* Duplicate (*.eml; *.msg) on Linux filepicker
Comment on attachment 146177 [details] [diff] [review]
Cleanup
[Checked in: Comment 28]

nice. I wonder if there aren't other places that can do this, e.g.,

http://lxr.mozilla.org/seamonkey/source/mailnews/compose/resources/content/MsgC
omposeCommands.js#2172
Attachment #146177 - Flags: superreview?(bienvenu) → superreview+
Out of luck there, unfortunately that code doesn't work for multiple files.

Robert did tell me that he copied the code, so there could be other places...
I'm looking at the 0416 Seamonkey build, and I'm disappointed in the results of 
this patch.  The menu changes are OK, as far as they go, except that  File|Open  
from any standalone message window opens the file picker correctly but doesn't 
actually open the file.  It would be swell if the picker in the *browser's*
 File|Open  could be extended with the "Mail Files" type (if MailNews is 
installed) and open into a message window if a .EML is selected.

The window that gets opened *is* a message window -- that is, it has the toolbar 
and menus -- but it doesn't handle the headers at all, let alone with an 
envelope panel like a regular message window does; it simply dumps the file 
contents into the window as text.  I can't check how attachments are rendered; 
quoted-printable is not decoded; HTML mail is shown as HTML source.

In fact, there is a regression here: it used to be that using  File|Open  of a 
.EML file from the browser would give me a display with most headers hidden and 
the major ones shown in a grey DIV at the top; this no longer happens (altho it 
*does* happen opening a message/rfc822 file via URL, e.g. attachment 137775 [details]).

Am I missing something?  Is/are there already another bug(s) open for these 
issues?
(In reply to comment #14)
> In fact, there is a regression here: it used to be that using  File|Open  of a 
> .EML file from the browser would give me a display with most headers hidden and 
> the major ones shown in a grey DIV at the top; this no longer happens (altho it 
> *does* happen opening a message/rfc822 file via URL, e.g. attachment 137775 [details]).

Yes, that is a new regression. I looked for a bug but I don't find one. In 1.7b
release it works, later it regressed (I tested builds 03-29 til 04-16 with
regression).
(In reply to comment #15)
> (In reply to comment #14)
> > In fact, there is a regression here: it used to be that using  File|Open  of 

Filed Bug 240942.
*** Bug 193281 has been marked as a duplicate of this bug. ***
So bug 240942 has been fixed, and (as it turns out) was a regression unrelated 
to this bug; just a coincidence that they landed at about the same time.  This 
is good!  But the issues I raised in comment 14 still apply, and I've opened a 
bunch of new bugs about them:

> The menu changes are OK, as far as they go, except that  File|Open  
> from any standalone message window opens the file picker correctly but
> doesn't actually open the file.

This is bug 241215.

> It would be swell if the picker in the *browser's*
>  File|Open  could be extended with the "Mail Files" type (if MailNews is 
> installed) and open into a message window if a .EML is selected.

This is bug 241216.

> The window that gets opened *is* a message window -- that is, it has the
> toolbar and menus -- but it doesn't handle [...]
> an envelope panel like a regular message window does

This is bug 241212.

In addition, I've opened bug 241213 about supporting commands like Reply, View 
Source, File|Attachments, etc. and disabling some items such as the Go menu, 
Create Filter from Message, etc.
*** Bug 242208 has been marked as a duplicate of this bug. ***
Reopening until JS strict warning and other cleanup fix is in.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Flags: blocking1.8a?
Flags: blocking1.8a? → blocking1.8a-
This should block 1.8a2.  

We have a patch by Neil, and it's sr=+.  

We just need mscott to r= and a checkin.
Flags: blocking1.8a2?
I'm working on a different but related feature, and there is one issue.

I'm loading .eml file into a <browser>, using browser.loadURI. If the message is
an HTML message with inline images, the images do not appear. 

The image encoding appears to be correct because if I open the file in the
Mozilla Browser, context click the image placeholder, and choose 'View Image',
the image appears.

Anyone else seeing this and/or know a workaround.

Has this feature been tested with HTML messages?
Attachment #146146 - Attachment description: proposed fix → proposed fix [Checked in: Comment 7]
Attachment #146146 - Attachment is obsolete: true
Comment on attachment 146177 [details] [diff] [review]
Cleanup
[Checked in: Comment 28]


No review from <mscott@mozilla.org> since "2004-04-15" :-(
Attachment #146177 - Flags: review?(mscott) → review?(ducarroz)
CC: Scott

I reassigned the review request in comment 23;
but may be you missed comment 11 which "answers" your comment 10 question ?

In any case, a review from you would still be the best choice !
(but if you have other priorities, may be Jean-Francois can help ?)

Thanks.
Flags: blocking1.8a2? → blocking1.8a2-
Comment on attachment 146177 [details] [diff] [review]
Cleanup
[Checked in: Comment 28]

sorry for the delay. R=ducarroz
Attachment #146177 - Flags: review?(ducarroz) → review+
Target Milestone: --- → mozilla1.8beta
Comment on attachment 146177 [details] [diff] [review]
Cleanup
[Checked in: Comment 28]

> # LOCALIZATION NOTES(EMLFiles): Do not translate "*.eml, *.msg" in the line below
>-EMLFiles=Mail Files (*.eml, *.msg)
>+EMLFiles=Mail Files

what's wrong with this picture? please fix before checking in.
Attachment #146177 - Flags: approval1.8a3?
Comment on attachment 146177 [details] [diff] [review]
Cleanup
[Checked in: Comment 28]

a=asa for checkin to 1.8a3
Attachment #146177 - Flags: approval1.8a3? → approval1.8a3+
Cleanup checked in.
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
Attachment #146177 - Attachment description: Cleanup → Cleanup [Checked in: Comment 28]
Attachment #146177 - Attachment is obsolete: true
Target Milestone: mozilla1.8beta1 → mozilla1.8alpha3
Attachment #146146 - Attachment is obsolete: false
Attachment #146177 - Attachment is obsolete: false
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: