Message window for .EML file needs envelope panel

VERIFIED FIXED

Status

SeaMonkey
MailNews: Message Display
VERIFIED FIXED
13 years ago
7 years ago

People

(Reporter: Mike Cowperthwaite, Assigned: Bienvenu)

Tracking

(Blocks: 1 bug, {fixed-seamonkey1.0, fixed-seamonkey1.1a, fixed1.8})

Trunk
fixed-seamonkey1.0, fixed-seamonkey1.1a, fixed1.8
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments, 2 obsolete attachments)

(Reporter)

Description

13 years ago
Thanks to the patch for bug 239555, it is now possible to directly open .EML 
files from Mail/News.  However, when the window opens, it does not render like 
normal message window; altho it has the message window's toolbar and menu, it 
lacks the 'envelope panel' which shows the headers and the attachment list, if 
any.

Instead, the message displays exactly as if the file had been opened in the 
browser.  Headers are shown in an unexpandable, abbreviated form with some 
styling to set them apart from the message body; but without the special XUL 
rendering and menu for addresses.

Worse, attachments in the mail are not usefully represented.  The display of 
them is poor (subject to bug 174692), and they do not have the standard 
attachment context menus (nor the File|Attachments menu, but that will be in a 
separate bug).  Image attachments (shown broken, per 174692) will generate the 
'Image' context menu -- and the View item works for this -- but the Save item 
works on the message source, not on the image.  (The Block/Unblock menu item 
makes no sense here, but that is bug 237858.)
cc--> bienvenu, the master.

This means making MsgOpenNewWindowForMessage smarter as I mentioned in bug 236637.
(Reporter)

Comment 2

13 years ago
Additional note: without the envelope, the title of the window is always "Mail & 
Newsgroups" instead of the subject line of the message.

Comment 3

13 years ago
There seem to be quite a few bugs relating to eml files not behaving as
expected. TB is the default email client on both WindowsXP and Windows2K PCs and
it does not seem possible to associate .eml files with TB so that when one
double clicks on the file the file opens in a ThunderBird window.

--drg
(Reporter)

Comment 4

13 years ago
(In reply to comment #3)
> it does not seem possible to associate .eml files with TB so that when one
> double clicks on the file the file opens in a ThunderBird window.

Bug 242959 and bug 261559.
Product: Browser → Seamonkey
Blocks: 279650
No longer blocks: 279650
Depends on: 279650
Depends on: 269826
Blocks: 279650
No longer depends on: 279650
Blocks: 269826
No longer depends on: 269826

Updated

12 years ago
Assignee: sspitzer → mail

Comment 5

12 years ago
There's a workaround:

You'll find the "TB Attachment Tools" at
http://www.supportware.net/mozilla/#ext9

Install them and you'll have a new "Import" function in Thunderbird's "File"
menu. You can use it to import an .eml file to a mail folder. From within there,
you can view the .eml and even access the attachments.
(Reporter)

Comment 6

12 years ago
(In reply to comment #5)
> There's a workaround:  [...]  "TB Attachment Tools"

I haven't installed it, but from the description, it appears to conflict with 
other changes for current trunk builds -- e.g., the "Delete All Attachments" 
feature is now part of TB.
(Assignee)

Updated

12 years ago
Assignee: mail → bienvenu
(Assignee)

Comment 7

12 years ago
The first cause of this is that when opening a .eml file, we're running a file:
url, instead of a mailbox url. This prevents us from associating a msg window
with the msg url, which prevents mime from finding the header sink. So either we
need to cons up a mailbox url from the file url, or we need to be able to get
and set the msg window on the file url. We might want to have a mailbox url for
other reasons, but it might have tricky side effects too. I'll investigate.
(Assignee)

Comment 8

12 years ago
Created attachment 184015 [details] [diff] [review]
proposed fix

this makes the header area display correctly by switching the file: url to a
mailbox url, and asking for the message at pos 0 in eml file. I also had to
change nsMailboxProtocol::SetupMessageExtraction to ask the mailbox url for the
message size directly first, and only if it doesn't know, get the size from the
msg hdr (we don't have a msg hdr in the .eml file case). And when running the
url, we set the message size based on the .eml file size.

What doesn't work with this patch is opening or saving attachments in .eml
files, for the same reason as above - we don't have a msg hdr with the message
size. To get that to work, I'm going to either need a msg header, or figure out
a way to play the same trick that we do when opening the original .eml file.
(Assignee)

Comment 9

12 years ago
*** Bug 253216 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 10

12 years ago
Created attachment 184692 [details] [diff] [review]
proposed fix

this patch uses a dummy header in msgHdrViewOverlay.js to store the message
size. With this patch, we can open .eml attachments/files in a stand-alone
message window, and open/save attachments within that message.

If I have time, I'll try to make reply/reply all work by populating the dummy
header from headers process in msgHdrViewOverlay.js, and using the dummy header
at reply time. I'd also like to get copy to a folder working.
(Assignee)

Updated

12 years ago
Attachment #184015 - Attachment is obsolete: true
Attachment #184692 - Flags: superreview?(mscott)

Comment 11

12 years ago
Comment on attachment 184692 [details] [diff] [review]
proposed fix

can we call is a DummyMsgHeader? 

this comment sounds like you didn't finish it:

// need to strip out ?type=x-message-display because it confuses
Attachment #184692 - Flags: superreview?(mscott) → superreview+
(Assignee)

Comment 12

12 years ago
I'll call it DummyMsgHeader and remove the "need to" part from the comment.
(Assignee)

Comment 13

12 years ago
Created attachment 184704 [details] [diff] [review]
forgot these files...
Attachment #184704 - Flags: superreview?(mscott)

Comment 14

12 years ago
Comment on attachment 184704 [details] [diff] [review]
forgot these files...

bump the interface ID on nsIMimeMiscStatus
Attachment #184704 - Flags: superreview?(mscott) → superreview+
(Assignee)

Updated

12 years ago
Attachment #184692 - Flags: approval-aviary1.1a2?
(Assignee)

Updated

12 years ago
Attachment #184704 - Flags: approval-aviary1.1a2?

Comment 15

12 years ago
Comment on attachment 184692 [details] [diff] [review]
proposed fix

a=chofmann
Attachment #184692 - Flags: approval-aviary1.1a2? → approval-aviary1.1a2+

Comment 16

12 years ago
Comment on attachment 184704 [details] [diff] [review]
forgot these files...

a=chofmann
Attachment #184704 - Flags: approval-aviary1.1a2? → approval-aviary1.1a2+
(Assignee)

Updated

12 years ago
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Comment 17

12 years ago
Created attachment 185150 [details] [diff] [review]
Suite port
Attachment #185150 - Flags: superreview?(bienvenu)
Attachment #185150 - Flags: review?(bienvenu)
(Assignee)

Comment 18

12 years ago
Comment on attachment 185150 [details] [diff] [review]
Suite port

mDummyHeader is going to grow a bit to handle other stuff, if I have time :-)
Attachment #185150 - Flags: superreview?(bienvenu)
Attachment #185150 - Flags: superreview+
Attachment #185150 - Flags: review?(bienvenu)
Attachment #185150 - Flags: review+

Updated

12 years ago
Attachment #185150 - Flags: approval1.8b3?
(Reporter)

Comment 19

12 years ago
verified fixed with TB 1.0+0603.  Thanks so much, David!  I'm looking forward to 
the fixes that will be possible now that this is in place.

I'd mark this bug verified except I haven't had a chance to check a suite build 
yet.

Updated

12 years ago
Attachment #185150 - Flags: approval1.8b3? → approval1.8b3+

Comment 20

12 years ago
Suite port checked in.
(Reporter)

Comment 21

12 years ago
(In reply to comment #20)
> Suite port checked in.

I just checked Moz 1.8b2-0621, and using File|Open to select a .EML file results 
in a window with the 3-pane menus and toolbar, and otherwise blank -- definitely 
not the desired result.
(Reporter)

Comment 22

12 years ago
(In reply to comment #21)
> (In reply to comment #20)
> > Suite port checked in.
> 
> I just checked Moz 1.8b2-0621, and using File|Open to select a .EML file
> results in a window with the 3-pane menus and toolbar, and otherwise blank --
> definitely not the desired result.

Still the case with SeaMonkey/1.0a-0806, Win2K -- and I'm also seeing the same 
thing with TB 1.0+0806, when running on Windows 98.  It works fine with TB under 
Win2K.
(In reply to comment #22)
> > I just checked Moz 1.8b2-0621, and using File|Open to select a .EML file
> > results in a window with the 3-pane menus and toolbar, and otherwise blank --
> > definitely not the desired result.
> 
> Still the case with SeaMonkey/1.0a-0806, Win2K -- and I'm also seeing the same 
> thing with TB 1.0+0806, when running on Windows 98.  It works fine with TB under 
> Win2K.

Error: uncaught exception: [Exception... "Component returned failure code:
0x80550006 [nsIMsgFolder.getMsgDatabase]"  nsresult: "0x80550006 (<unknown>)" 
location: "JS frame :: chrome://messenger/content/messageWindow.js :: CreateView
:: line 358" data: no]

Just pasting Mike's JS exception so we know _what's_ happening, but not _why_, yet.

Comment 24

12 years ago
I've figured out that I can reproduce Mike's bug by loading Account Central for
Local Folders (or for any account except IMAP or news).
What I don't know is what the correct fix is.
a) GetMsgDatabase should always return NS_OK as per remote accounts
b) GetMsgDatabase returns special success codes instead of failure codes
c) Some JS callers have to be wrapped in try/catch just in case
(Reporter)

Comment 25

12 years ago
(In reply to comment #24)
> I've figured out that I can reproduce Mike's bug by loading Account Central

Good catch, Neil -- once I selected an account, the message window opened fine. 
And the trunk version of TB is showing the same symptom -- I'd never tried 
opening a message with AC showing.

Does this problem need a new bug?
(Assignee)

Comment 26

12 years ago
I'm going to re-open this. It seems to have regressed for me, both on the 1.8
branch and the trunk. I can save an attachment, but can't open one.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 27

12 years ago
Created attachment 193489 [details] [diff] [review]
enable opening of attachments from .eml files opened in stand-along window

use url instead of message uri.
Attachment #193489 - Flags: superreview?(mscott)
(Assignee)

Comment 28

12 years ago
Created attachment 193490 [details] [diff] [review]
fix case when account central is selected
Attachment #193490 - Flags: superreview?(mscott)

Comment 29

12 years ago
Comment on attachment 193489 [details] [diff] [review]
enable opening of attachments from .eml files opened in stand-along window

>+  PRInt32 typeIndex = urlString.Find("?type=application/x-message-display");
>+  if (typeIndex != kNotFound)
>+  {
>+    urlString.Cut(typeIndex, sizeof("?type=application/x-message-display") - 1);
>+    // we also need to replace the next '&' with '?'
>+    PRInt32 firstPartIndex = urlString.FindChar('&');
>+    if (firstPartIndex != kNotFound)
>+      urlString.SetCharAt('?', firstPartIndex);
If there is a character following "display" then it should be the & that you
seek...

>+    return docShell->LoadURI(URL, loadInfo, nsIWebNavigation::LOAD_FLAGS_NONE, PR_FALSE);
nsIWebNavigation::LOAD_FLAGS_IS_LINK perhaps?

Updated

12 years ago
Attachment #193490 - Flags: superreview?(mscott) → superreview+

Comment 30

12 years ago
Comment on attachment 193489 [details] [diff] [review]
enable opening of attachments from .eml files opened in stand-along window

I don't know what the answer is to Neil's comment about using LOAD_FLAGS_LINK.
I know everywhere else where we are opening similar type urls, we pass in
LOAD_FLAGS_NONE in the mailnews.
Attachment #193489 - Flags: superreview?(mscott) → superreview+

Comment 31

12 years ago
Comment on attachment 193490 [details] [diff] [review]
fix case when account central is selected

>     // this is a hack to make opening a stand-alone msg window on a 
>@@ -392,6 +393,12 @@
>     // of not having a folder.
Since you didn't use enough -u I shall have to quote the entire comment:
// this is a hack to make opening a stand-alone msg window on a 
// .eml file work. We use a search view since its much more tolerant
// of not having a folder.
Maybe tweak MsgOpenFromFile to actually trigger this hack?
(Assignee)

Comment 32

12 years ago
Created attachment 193509 [details] [diff] [review]
fix inspired by Neil.

pass in null for the folder uri by calling window.openDialog directly.
Attachment #193490 - Attachment is obsolete: true
Attachment #193509 - Flags: review?(neil.parkwaycc.co.uk)
(Assignee)

Comment 33

12 years ago
Comment on attachment 193509 [details] [diff] [review]
fix inspired by Neil.

I think Neil is going to prefer this patch to the other patch, Scott, so I
think this is the one I'd like sr'ed and checked into the trunk for tbird.
Attachment #193509 - Flags: superreview?(mscott)

Comment 34

12 years ago
Comment on attachment 193509 [details] [diff] [review]
fix inspired by Neil.

Do you still need to pass gDBView? Also, when I ported the fix to Suite I also
had to make three other changes which Thunderbird might or might not have.
Attachment #193509 - Flags: review?(neil.parkwaycc.co.uk) → review+

Comment 35

12 years ago
Created attachment 193593 [details] [diff] [review]
Suite port (checked in trunk/branch 1.8 & 1.8.0)
Attachment #193593 - Flags: superreview?(bienvenu)
Attachment #193593 - Flags: review?(mnyromyr)
(Assignee)

Comment 36

12 years ago
Comment on attachment 193593 [details] [diff] [review]
Suite port (checked in trunk/branch 1.8 & 1.8.0)

there is no nsMsgViewType.eSearch - it's eShowSearch, at least in my tree.
Tbird already has that code (modulo eSearch->eShowSearch)

the tbird OnLoadMessageWindowDelayed  starts like this:

  if (loadCustomMessage)
  {
    gDBView.suppressMsgDisplay = false;

and I don't know about the third change, I didn't need to do that. Re passing
in the view, passing in null is ok, and may be better, I don't know - if you
pass in a view, we'll clone it, which is pretty fast, but creating a search
view that you don't use is probably faster.
(Assignee)

Comment 37

12 years ago
Comment on attachment 193489 [details] [diff] [review]
enable opening of attachments from .eml files opened in stand-along window

this fix is not without its terrors since attachment handling is always fun.
The effect should be limited to opening attachments from local mail messages,
and I've tested it for a while. My fear is that if we don't take this fix for
1.5, we'll get a ton of bugs filed on this once people discover 1.5's improved
.eml file handling.
Attachment #193489 - Flags: approval1.8b4?
(Assignee)

Comment 38

12 years ago
reclosing, fixes checked in.
Status: REOPENED → RESOLVED
Last Resolved: 12 years ago12 years ago
Resolution: --- → FIXED
(Assignee)

Updated

12 years ago
Attachment #193509 - Flags: approval1.8b4?

Comment 39

12 years ago
Comment on attachment 193509 [details] [diff] [review]
fix inspired by Neil.

approving for the 1.8b4 branch. Low risk change.
Attachment #193509 - Flags: superreview?(mscott)
Attachment #193509 - Flags: superreview+
Attachment #193509 - Flags: approval1.8b4?
Attachment #193509 - Flags: approval1.8b4+

Comment 40

12 years ago
Comment on attachment 193489 [details] [diff] [review]
enable opening of attachments from .eml files opened in stand-along window

make sure bz's mime type change for application/x-message-display is on the
branch before checking this in. It looks to me like it is in the 1.8 branch.
Attachment #193489 - Flags: approval1.8b4? → approval1.8b4+
(Assignee)

Updated

12 years ago
Keywords: fixed1.8
(Reporter)

Comment 41

12 years ago
Altho the message window is opening correctly, the JavaScript console is full of 
errors: there are multiple instances (exact number appears to depend on the 
message, i.e. whether it has an attachment) of:
===
Error: [Exception... "'JavaScript component does not have a method named: 
"getStringProperty"' when calling method: [nsIMsgDBHdr::getStringProperty]"  
nsresult: "0x80570030 (NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED)"  location: 
"<unknown>"  data: no]
===
followed by one each of:
===
Error: [Exception... "Component returned failure code: 0x80004005 
(NS_ERROR_FAILURE) [nsIMsgMailNewsUrl.folder]"  nsresult: "0x80004005 
(NS_ERROR_FAILURE)"  location: "JS frame :: chrome://messenger/content/
mailWindowOverlay.js :: OnMsgLoaded :: line 2243"  data: no]
Source File: chrome://messenger/content/mailWindowOverlay.js
Line: 2243

Error: [Exception... "Component returned failure code: 0x80004005 
(NS_ERROR_FAILURE) [nsIMsgMailNewsUrl.folder]"  nsresult: "0x80004005 
(NS_ERROR_FAILURE)"  location: "JS frame :: chrome://messenger/content/
phishingDetector.js :: isMsgEmailScam :: line 24"  data: no]
Source File: chrome://messenger/content/phishingDetector.js
Line: 24
===

TB 1.5b1-0904, TB 1.6a1-0830, Win2K

David, do you want to reopen this, or should I open a new bug?
(Assignee)

Comment 42

12 years ago
were those warnings fixed by another bug?
(Reporter)

Comment 43

12 years ago
(In reply to comment #42)
> were those warnings fixed by another bug?

Are you saying you don't see the errors?  (They're not warnings.)  If so, which 
build are you using?

(In reply to comment #41)
> TB 1.5b1-0904, TB 1.6a1-0830, Win2K

I can update this to: 1.6a1-0904 shows the errors.  I haven't gotten a new build 
since 9/4 because there have been hardly any mail-related patches checked in 
since 9/4, none of any interest to me.  (Getting a new build is nontrivial for 
those of us on dialup.)
(Assignee)

Comment 44

12 years ago
I do see these warnings, even after updating. It might depend on the message. I
wasn't seeing so many of them on other messages.

Comment 45

12 years ago
Comment on attachment 193593 [details] [diff] [review]
Suite port (checked in trunk/branch 1.8 & 1.8.0)

Neil, is this patch still needed? Opened .eml files are shown as expected with
my current trunk build, even without the patch.

Regardless of the patch being applied or not, I can see the warnings mentioned
in comment 41, but only if a folder (not an account) is selected; switching
View->Headers->* doesn't work then.
If an account is selected, the message windows open, but doesn't display the
message...
(Reporter)

Comment 46

12 years ago
(In reply to comment #45)
> Regardless of the patch being applied or not, I can see the warnings mentioned
> in comment 41, but only if a folder (not an account) is selected; switching
> View->Headers->* doesn't work then.

With TB 1.5b1-0904, I don't see any difference between opening with an account 
selected and with a folder selected -- many error messages displayed.  (David 
supplied a patch at bug 268746 to correct for the missing-getStringProperty-
method errors, checked in today.)

Most of the View menu doesn't work, and hasn't since opening a .EML file was 
first implemented; see bug 241213.
(Reporter)

Comment 47

12 years ago
(In reply to comment #46)
> (David supplied a patch at bug 268746 to correct for the missing-
> getStringProperty- method errors, checked in today.)

And it's working, in today's nightly TB build; but the other two errors from 
comment 41 still exist.

Comment 48

12 years ago
Comment on attachment 193593 [details] [diff] [review]
Suite port (checked in trunk/branch 1.8 & 1.8.0)

Okay, the patch *does* make a difference insofar as you can't open .emls
without it if just an accout is selected...
(And don't forget to change the eSearchs into eShowSearch on checkin! ;-) )
Attachment #193593 - Flags: review?(mnyromyr) → review+
(Assignee)

Updated

12 years ago
Attachment #193593 - Flags: superreview?(bienvenu) → superreview+

Updated

12 years ago
Attachment #193593 - Attachment description: Suite port → Suite port (checked in)
(Reporter)

Comment 49

12 years ago
*** Bug 239685 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 50

12 years ago
I'm a little confused as to the state of the patches, but: Seamonkey 1.0a-0910 
(the most recent 1.0a I could find on ftp.mozilla.org) still has the problem of 
not displaying the message if an account, rather than a folder, is selected in 
the Folder pane.

Comment 51

12 years ago
(In reply to comment #50)
>I'm a little confused as to the state of the patches, but: Seamonkey 1.0a-0910 
>(the most recent 1.0a I could find on ftp.mozilla.org) still has the problem of 
>not displaying the message if an account, rather than a folder, is selected in 
>the Folder pane.
That's because the branch doesn't have the Suite port.
Flags: blocking-seamonkey1.0b?
No longer blocks: 279650

Comment 52

12 years ago
Comment on attachment 193593 [details] [diff] [review]
Suite port (checked in trunk/branch 1.8 & 1.8.0)

Only TB version has been checked into branch, not port version
Attachment #193593 - Flags: approval-seamonkey1.0?

Updated

12 years ago
Attachment #193593 - Flags: approval-seamonkey1.1+
Attachment #193593 - Flags: approval-seamonkey1.0?
Attachment #193593 - Flags: approval-seamonkey1.0+

Comment 53

12 years ago
Comment on attachment 193593 [details] [diff] [review]
Suite port (checked in trunk/branch 1.8 & 1.8.0)

Checking in (branch 1.8)
commandglue.js;
new revision: 1.258.4.3; previous revision: 1.258.4.2
mailWindowOverlay.js;
new revision: 1.222.2.5; previous revision: 1.222.2.4
messageWindow.js;
new revision: 1.105.2.3; previous revision: 1.105.2.2
done
Checking in (branch 1.8.0)
commandglue.js;
new revision: 1.258.10.2; previous revision: 1.258.10.1
mailWindowOverlay.js;
new revision: 1.222.2.3.4.2; previous revision: 1.222.2.3.4.1
messageWindow.js;
new revision: 1.105.2.1.4.2; previous revision: 1.105.2.1.4.1
done
Attachment #193593 - Attachment description: Suite port (checked in) → Suite port (checked in trunk/branch 1.8 & 1.8.0)

Updated

12 years ago
Whiteboard: fixed-seamonkey1.0

Updated

12 years ago
Blocks: 323539
Keywords: fixed-seamonkey1.0
Whiteboard: fixed-seamonkey1.0
(Reporter)

Comment 54

11 years ago
Regarding the errors cited in comment 41: the 'getStringProperty()' errors have been fixed [bug 268746]; I've opened bug 338536 for the other two.
Status: RESOLVED → VERIFIED

Updated

11 years ago
Keywords: fixed-seamonkey1.1a
Bug was fixed in SM 1.0
Flags: blocking-seamonkey1.0b?
You need to log in before you can comment on or make changes to this bug.