|
Randor wrote: "MHT" literally means MIME hyper text.
MHT RFC MIME[^]
Yes, MHT does mean MIME HTML. Well done.
However...
As RFC2557 (one of the RFCs you indirectly linked to) specifies, MHT/MHTML files are aggregate documents that can contain a serialised or archived HTML page including subsidiary components. As such, MHT/MHTML is essentially identical to the EML format.
Why is this relevant?
Because, in the context of the OP's question, a mail client program (such as Outlook) can save the content of an email into a MHT file so that the content can be viewed locally in a web browser or other program that supports the MHT/MHTML/EML format.
When the content is saved locally for viewing in such a manner, no MIME type is involved in terms of opening the target program. Let me say that again in slightly different terms: Even though the word "MIME" is part of the name "MHT" or "MHTML", it is still the case that no MIME type is involved in allowing a source program to open a target program to open the file via the shell. Only the file extension matters in this context. The Windows shell knows nothing of the MIME type of a file when a file is being passed from a source program to a target program to be opened.
I note also that you did not address the issue that COM is not needed in the context of the subject at hand: That of one program opening another to handle a file via the Windows shell.
|
|
|
|
|
markrlondon wrote: open a target program to open the file via the shell.
1.) Outlook is not opening MHT files via the shell.
2.) There is no default handler for MHT file extensions in the Windows operating system.
3.) Outlook is invoking the Outlook MHTML protocol handler which is written as a COM component.
Outlook MHTML protocol handler[^]
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: 1.) Outlook is not opening MHT files via the shell.
[...]
3.) Outlook is invoking the Outlook MHTML protocol handler which is written as a COM component
In that case I accept that we have been speaking at cross purposes. From @OriginalGriff's original message I was under the impression that Outlook was simply saving the email as a MHT file in some temporary location and then invoking whatever was the user's current default MHT handler in the shell to view the file.
Indeed, if Outlook says "click here to open in your browser" then this is, indeed, the behaviour I would expect: That is to open in the browser currently set to handle MHT files, not in Outlook's own protocol handler.
Randor wrote: 2.) There is no default handler for MHT file extensions in the Windows operating system.
Eh? Yes, there is. As of when I last checked, out of the box in Windows 10, Internet Explorer is registered as the default handler in the shell for .MHT and .MHTML files. I'll check this on a fresh install right now and confirm.
modified 6-Oct-20 12:52pm.
|
|
|
|
|
markrlondon wrote: we have been speaking at cross
You seem to have an argumentative personality. This XKCD[^] pretty much sums it up. There was no reason to have this long debate over this trivial matter.
markrlondon wrote: I'll check this on a fresh install right now and confirm.
interesting, keep me informed of your mind-bending discoveries. You should investigate the ftype command[^] while you are learning how to use the operating system.
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: You seem to have an argumentative personality
ROFL! And it looks to me like you are projecting. 
modified 6-Oct-20 13:34pm.
|
|
|
|
|
markrlondon wrote: Randor wrote: 1.) Outlook is not opening MHT files via the shell.
[...]
3.) Outlook is invoking the Outlook MHTML protocol handler which is written as a COM component
In that case I accept that we have been speaking at cross purposes. From @OriginalGriff's original message I was under the impression that Outlook was simply saving the email as a MHT file in some temporary location and then invoking whatever was the user's current default MHT handler in the shell to view the file.
Indeed, if Outlook says "click here to open in your browser" then this is, indeed, the behaviour I would expect: That is to open in the browser currently set to handle MHT files, not in Outlook's own protocol handler.
Actually I've just this second tested this in Outlook 2019 and I was right all along!: When I click 'View in Browser', Outlook saves the email as a MHT file (in my case in "C:\Users\myname\AppData\Local\Microsoft\Windows\INetCache\Content.Outlook\VPRZWED6\email.mht") and then runs the browser currently set in the shell as the .MHT handler to view the file. On my machine, since I have never changed the default browser for MHT files, this is Internet Explorer.
If Outlook is still using the Outlook MHTML COM component in some way to do this, it is complicating it enormously. Such a component is completely unnecessary in this context (and the use of COM to open the browser is also unnecessary). It could all by done without COM, as most other programs do it.
markrlondon wrote: I'll check this on a fresh install right now and confirm.
Am still downloading the latest W10 Enterprise trial.
|
|
|
|
|
 markrlondon wrote: markrlondon wrote: Randor wrote: 1.) Outlook is not opening MHT files via the shell.
[...]
3.) Outlook is invoking the Outlook MHTML protocol handler which is written as a COM component
In that case I accept that we have been speaking at cross purposes. From @OriginalGriff's original message I was under the impression that Outlook was simply saving the email as a MHT file in some temporary location and then invoking whatever was the user's current default MHT handler in the shell to view the file.
Indeed, if Outlook says "click here to open in your browser" then this is, indeed, the behaviour I would expect: That is to open in the browser currently set to handle MHT files, not in Outlook's own protocol handler.
Actually I've just this second tested this in Outlook 2019 and I was right all along!: When I click 'View in Browser', Outlook saves the email as a MHT file (in my case in "C:\Users\myname\AppData\Local\Microsoft\Windows\INetCache\Content.Outlook\VPRZWED6\email.mht") and then runs the browser currently set in the shell as the .MHT handler to view the file. On my machine, since I have never changed the default browser for MHT files, this is Internet Explorer.
Furthermore, I have just selected Edge (Chromium Edge) as the default handler for both .MHT and .MHTML files and I can now replicate @OriginalGriff's problem: Edge shows a plain text rendition of the file whereas the very same file opened in Internet Explorer is rendered properly.
The problem is nothing to do with COM or anything like it. (Blame it on the MHTML COM component which I can see may well be used to generate the MHT files, if you want, but the actual problem is still nothing to do with COM. And the browser is not being opened via COM and COM is not used to pass the file to open).
I've done some more testing and the problem is within Edge's interpretation of .MHT files. When I use Outlook's 'View in Browser' option, it generates a MHT file that Internet Explorer can render correctly whereas Edge cannot. When I use Thunderbird to save the same email to a MHT file, I get the same end result: Internet Explorer can successfully render the file whereas Edge shows me a text rendition instead.
Chromium Edge can, however, successfully render MHT files saved from browsers: I have tested MHT files saved from Chromium Edge itself, Internet Explorer, Firefox with UnMHT, and Waterfox with UnMHT, and they are all rendered successfully in both IE and Edge.
So there is something about emails saved as MHTs that Edge can't render properly. I'll investigate this more and report back.
I'd also like to re-iterate that Outlook really does appear to be doing what I thought it was all along: It is saving the email as a MHT file to the file system (as above) and then running the user's currently set MHT handler to open it.
modified 6-Oct-20 14:13pm.
|
|
|
|
|
markrlondon wrote: I've done some more testing and the problem is within Edge's interpretation of .MHT files. When I use Outlook's 'View in Browser' option, it generates a MHT file that Internet Explorer can render correctly whereas Edge cannot. When I use Thunderbird to save the same email to a MHT file, I get the same end result: Internet Explorer can successfully render the file whereas Edge shows me a text rendition instead.
Chromium Edge can, however, successfully render MHT files saved from browsers: I have tested MHT files saved from Chromium Edge itself, Internet Explorer, Firefox with UnMHT, and Waterfox with UnMHT, and they are all rendered successfully in both IE and Edge.
So there is something about emails saved as MHTs that Edge can't render properly. I'll investigate this more and report back.
I'd need to hand-craft some MHT files to test this more fully but it looks to me as if Edge cannot properly render MHTs with a primary Content-Type of multipart/alternative. If the first alternative sub-part is text/plain then it renders that and not the alternative text/html version.
Internet Explorer, on the other hand, correctly renders the text/html alternative in a MHT that has a multipart/alternative primary type (and ignores the text/plain alternative).
Most MHTs saved from browsers, however, have a primary type of 'multipart/related; type="text/html"' which both IE and Edge can successfully render.
I wonder if this is a bug or a deliberate design choice in Edge.
Either way, it's nothing to do with registered COM objects. The bug is not in Outlook or the MimeOLE component.
|
|
|
|
|
markrlondon wrote: Edge cannot properly render MHTs with a primary Content-Type of multipart/alternative.
Are you aware that you literally spent the last 24 hours arguing that MIME types were not involved? Now you're telling me that you have discovered that the MIME (Content-Type) is causing the problem.
Why do you find this topic so important? After discovering that MIME types are indeed what's causing the issue, go back and read your previous statements.
|
|
|
|
|
Randor wrote: Are you aware that you literally spent the last 24 hours arguing that MIME types were not involved? Now you're telling me that you have discovered that the MIME (Content-Type) is causing the problem.
(a) I stated that MIME types were not involved in a source program selecting which target program to open for a particular file. I was and am completely correct. It is indeed the case that MIME types are not involved in any way, shape or form in the process of a source program finding the correct target program to open a particular file type via the shell.
(b) I am now pointing out that the value of the primary Content-Type header of MHT files marks a difference between how Internet Explorer and Edge render MHT files. This is new information. It could well be a bug in Edge.
Got it now?
Randor wrote: Why do you find this topic so important?
I must bring to your attention the fact that you are choosing to discuss this with me. Why is it so important to you?
After discovering that MIME types are indeed what's causing the issue, go back and read your previous statements.
My previous statements were and are completely correct. Read over them again. As I noted above in this message (and as I have said all along), MIME types have no connection whatsoever with a program such as Outlook opening a program such as a web browser to display a MHT file that Outlook has saved in the file system. And yes, despite your incorrect claims to the contrary, Outlook does save the MHT file in the file system.
Only the file extension defines what the target program should be in this scenario, not its MIME type. You incorrectly claimed that MIME types were involved in this process (seemingly, as far as I can tell, because you thought it was a HTTP download issue and not a shell issue).
A wholly new discovery (to you too, I hope you don't try to pretend otherwise) is that the reason for @OriginalGriff's reported bug is what seems to be an error in Edge's processing of MHT files (when compared to Internet Explorer). Whilst this is certainly to do with the MIME structure of MHT files it is still nothing to do with which target program is opened, which was the subject of my earlier comments about MIME types. As an aside, it also means that your analysis of the reason for the @OriginalGriff's error was wrong.
|
|
|
|
|
At least you are very good at debate. The technique you are using is called gish gallop[^]. A laymen reading this will not be able to determine which is author is correct. It would take a subject matter expert to look deeper.
Anyway, this is getting nowhere and I don't want to be a part of this anymore.
|
|
|
|
|
The "technique" I have used is to test reality versus both your claims and my own claims, and reality has shown that I was correct in what I said. I have done no more than to point this out, honestly, fully and thoroughly.
The records of what you and I have said are here for anyone and everyone to see. These issues are not matters of opinion where subjective views can legitimately differ. Instead, the issues under discussion are all objectively provable through empirical testing, one way or another. They can be tested in Outlook and in Windows, and I have actually done this and recorded the objective results in this thread. The results showed my claims to to correct.
And as part of my testing I discovered what seems to be a bug in Chromium Edge (compared to IE).
Anyone who is interested and who wishes to work through the debate can see all of this. This is a forum for software developers, afterall, so it should not be surprising that the issues are technical. Nevertheless, it's all there for anyone sufficiently interested.
|
|
|
|
|
I have reviewed my comments and cannot find anything incorrect in my response to the poster.
The Lounge[^]
The Lounge[^]
Can you highlight exactly which statement you believe is incorrect for me?
|
|
|
|
|
Sh!4, I admit it. Whilst you really did make mistakes, I made one too. Read on.
Here: 04/10/20 21:38, The Lounge[^] : You wrote that "I would hazard a guess that the display problem @OriginalGriff is having is caused by Outlook generating a MHT file with the MIME type set to 'Content-Type: text/plain'" and I rejected this as a possibility because I misread what you meant. I'm really sorry.
In fact you identified pretty much the exact bug I later found, except that as far as I can see it is a bug in Edge, not Outlook. Outlook (or MimeOLE) seems to me to create correct MHT files for emails and it is (or should be) up to Edge to replicate IE's behaviour by rendering the text/html part and not the text/plain part in such a MHT.[1]
Here is why I got the wrong end of the stick: You referred to the Content-Type header within the MHT file as "the MIME type" and for some reason I read it as if you were referring to the MIME type in a HTTP download. I completely got the wrong end of the stick on that.
I am really sorry about that. I should have been more cautious.
However, you did then go on to say that "The reason it opens in IE11 is an operating system team build issue" and that is certainly an error. The reason the MHT file opens in IE is because IE is the default handler for .MHT and .MHTML files. This is, as I said, nothing to do with COM. I fully appreciate that the CLSID you refer to in that message points to the component Outlook uses to generate the MHT file but it is absolutely not the reason that IE is then used to open the file.
You also went on to say that "A COM object wrapper for launching Chromium-Edge does not exist yet" but this would not in and of itself change anything in terms of IE still being the default handler for .mht/.mhtml files in the registry.
So, I apologise very humbly for getting the wrong end of the stick but you did make mistakes too. MIME is of course not used to select the target program to open a file but, I now realise, you never said it did!
On the other hand, I was right to say that COM was and is irrelevant to the way that IE or Edge are opened to view the saved MHT file.
Also you also went on to say in a later message that "Outlook is not opening MHT file via the shell" but, as I pointed out, it's the other way: Outlook demonstrably does save MHT files (generated by the COM component) to the file system and then uses the shell to run a target program to open the saved MHT file.
Anyway, I apologise for my error to begin with. We both made errors of fact and of interpretation.
Footnote:-
1: Just to recap the Edge bug for reference: As I went on to mention, Thunderbird creates MHT files with text/plain and text/html parts within a multipart/alternative structure exactly as Outlook/MimeOLE do, so I think it is Edge that needs to change to match IE's behaviour in terms of rendering the text/html part in a multipart/alternative structure. Both IE and Edge successfully render web pages saved by browsers into MHT files since these all seem to use multipart/related;type="text/html" structures instead.
** edit ** Fixed the message link.
modified 6-Oct-20 21:46pm.
|
|
|
|
|
markrlondon wrote: 2.) There is no default handler for MHT file extensions in the Windows operating system.
Eh? Yes, there is. As of when I last checked, out of the box in Windows 10, Internet Explorer is registered as the default handler in the shell for .MHT and .MHTML files. I'll check this on a fresh install right now and confirm.
Just checked with a fresh install of the trial version of W10 Enterprise 2004 and, yes, there is a default handler for .MHT and .MHTML files in Windows 10 and, as I said, it is Internet Explorer.
Here are the relevant parts from the registry:
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.mht]
@="mhtmlfile"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.mhtml]
@="mhtmlfile"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mhtmlfile\DefaultIcon]
@=%ProgramFiles%\Internet Explorer\iexplore.exe,-32554
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mhtmlfile\shell\open\command]
@="\"C:\\Program Files\\Internet Explorer\\iexplore.exe\" %1"
Or if you prefer the output of ftype:
>ftype mhtmlfile
mhtmlfile="C:\Program Files\Internet Explorer\iexplore.exe" %1
|
|
|
|
|
Heh,
I have not confirmed it, but I believe you. Congratulations, you found one thing I said that might not be correct. This is funny, you are picking through everything I say looking for at least one thing I say that might be wrong. I have never had anyone do this to me, I can't figure out your motivation. This is a very unpleasant experience.
I can tell you that the older that I get (I am an old man) I expect to be wrong more often. But as an experienced software engineer that contributed to Windows 8,8.1, and 10 at Microsoft in the operating systems group I hope that I can contribute and help others here on codeproject.com and have a positive impact. I try to avoid conflict and I try to share my experience and wisdom with others.
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: I have never had anyone do this to me, I can't figure out your motivation. This is a very unpleasant experience.
If one makes mistakes on technical subjects in a technical forum, one should not be surprised if they are pointed out. I have done this, honestly and truthfully, on this particular subject. I too make mistakes and have had them pointed out. However, I've not made any technical errors in this particular thread.
I'm not pursuing you in any special way. I'd have done the same if it had been anyone else saying the particular things that you said here. I had never heard of you before this thread.
Randor wrote: But as an experienced software engineer that contributed to Windows 8,8.1, and 10 at Microsoft in the operating systems group I hope that I can contribute and help others here on codeproject.com and have a positive impact.
I'm sure you do help people and do have a positive impact. But this does not mean that you are especially immune to scrutiny. All of us on technical forums place ourselves open to scrutiny. Some of us could practice some humility, of course. 
I welcome scrutiny. I am confident in the technical accuracy of everything I have said in this thread.
Randor wrote: I try to avoid conflict and I try to share my experience and wisdom with others.
I understand. I don't think this is conflict. I see it just a search for objective truth based upon testing and evidence. I have done the empirical testing and provided the evidence for my claims.
|
|
|
|
|
lol,
You are seriously very good at debating. My statements at the top of the thread to @OriginalGriff were completely accurate. I have reviewed them multiple times.
The Lounge[^]
The Lounge[^]
If you are wondering why Apple, Microsoft, Facebook and Google has tens of thousands of engineers and why they almost never post on public forums... what is happening right now is why. It is easy for something like this to happen and get into a long drawn out ugly debate. A talented debater can make it look really ugly and hard for laymen to figure out factual statements.
I am retreating, you win the debate!
Best Wishes,
-David Delaune
|
|
|
|
|
Randor wrote: You are seriously very good at debating.
I'm genuinely flattered, although I'm not entirely sure you meant it to be a compliment. However, in this case it's mostly just connected with my making a mistake.  See my other message at [^].
Randor wrote: My statements at the top of the thread to @OriginalGriff were completely accurate. I have reviewed them multiple times.
The Lounge[^]
See my message linked above about this one. As per my other message, I readily admit that I deeply misread what you wrote about the Content-Type header and I am really sorry about that. But, as I also pointed out, you did make a mistake too. Your message was not completely accurate.
Randor wrote: The Lounge[^]
I did not in fact reply to this one as far as I can see now but you did say once again that it was an "operating system build problem" which is not the case. The issues that @OriginalGriff mentioned are not due to the OS build at all. You also referenced the COM object again which is irrelevant in as much as it doesn't tell us anything about how Outlook finds the correct target program to run (despite the fact that Outlook uses it to generate the MHT file).
Randor wrote: If you are wondering why Apple, Microsoft, Facebook and Google has tens of thousands of engineers and why they almost never post on public forums... what is happening right now is why.
But you're not representing your employer here. If you hadn't said "we" I'd never have known you work for Microsoft. In my view, unless specifically announced otherwise, everyone here just represents themselves.
Randor wrote: A talented debater can make it look really ugly and hard for laymen to figure out factual statements.
With the best will in the world, this seems to me to be something of a straw man. That sounds provocational but it's not meant to be. I just mean that not every debate has to be suitable for laymen and this debate is, in my opinion, not one of them. Only people who are interested and have some awareness of the technical issues would be able to follow it, and that's not a weakness imo. It's just the way it is.
As I say, I apologise for my mistake in misreading your comment about Content-Type headers. But, as I have noted, you did make some mistakes too.
|
|
|
|
|
markrlondon wrote: but you did say once again that it was an "operating system build problem" which is not the case.
I said it was a build problem because the registry keys relating to MHT files and protocol are set by the Windows 10 build process. When I make comments like this I am looking at the problem from the perspective of someone with intimate knowledge of the Windows 10 build process.
This has happened before:
Back in March, 2019 Rick York found a bug where GetFileVersionInfoW was causing an issue[^]. He blamed it on the Visual Studio team. What he didn't know was that it was ME personally that moved GetFileVersionInfoW into the Mincore library when I was working on OneCore. He was blaming it on the Visual Studio team and I pointed out that the API was actually part of the operating system build process and the Visual Studio team was just using our API constructed during the build.
I am under perpetual NDA and I can easily get in big trouble discussing internal things like this online. I guess I will just stop responding to technical issues relating to Microsoft.
modified 7-Oct-20 9:29am.
|
|
|
|
|
OriginalGriff wrote: Just like Chrome, it opens it as raw text, and displays the HTML.
It's possible that prior to the new Chromium version it did, just like it used to support epub files.
I can confirm that the current, publicly available, Chromium-based Edge fully supports MHT. I use it all the time to create and view MHTs. It also works successfully to view MHTs generated with IE or Firefox/Waterfox/UnMHT.
If yours doesn't show MHTs successfully then I guess you have a misconfiguration in your system. Can you send me one of the MHTs and I'll see if it opens successfully for me in my Edge.
|
|
|
|
|
markrlondon wrote: If yours doesn't show MHTs successfully then I guess you have a misconfiguration in your system. Can you send me one of the MHTs and I'll see if it opens successfully for me in my Edge.
Oops sorry, I see you've already tested with another MHT.
|
|
|
|
|
My more important email accounts (aka work) are handled by the full-blown Outlook client, but I otherwise use Win10's built-in client for my personal email. Things I probably don't need to hang on to for a long time and will probably get nuked sooner or later. Amazon's stuff falls in that category.
Their emails tend to end up in my junk mail folder, where images are blocked. If I really want to read them, I just drag the message onto the inbox, and read it from there, with the images unblocked automatically.
|
|
|
|
|
OriginalGriff wrote: So it ... opens it in IE11 ... 
So a moments thought tells me why: Outlook looks at the email in HTML and packages it in a MHT file and uses the default app to open those via Process.Start (or similar). Unfortunately, neither Chrome nor Edge support MHT files anymore, so it digs up the oldest browser it can find on the computer and uses that ...
Edge certainly does support MHTs and it's very fast for both saving and reading them. It's faster than either IE or Waterfox with the UnMHT addon. (UnMHT no longer works in Firefox).
(I'm not sure whether or not this feature is inherited from Chrome/Chromium or added by Microsoft. Kudos to the Edge dev team for adding it if is their work).
The only reason the MHTs open in IE and not Edge is that you haven't selected Edge to be your default app for MHTs. You can do this through the usual 'Choose default applications by file type' in Settings.
However, it would help if Outlook itself was aware of this issue and gave you an alert to tell you what MHTs viewers are installed on your system. Whilst it can no longer directly change preferences (due to a preference-signing addon that Microsoft added to apps muckong around which people's preferences), it could tell you where to go to change your MHT preference.
modified 3-Oct-20 19:44pm.
|
|
|
|
|
So, staying at home and no family outing lead to my car being idle for too long (used once around 1+ month back). Did not anticipate that around a month without use would add another task to my TODO list.
One of the task to close on today - get mechanic and get it jump started and charge up the battery. 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
