From:  Paul Schauble <>
Date:  14 Jul 2019 10:05:42 Hong Kong Time

Re: TBird can't save *anything*, part 2


I am back from vacation. 

I must apologize. My initial post was rushed since I wanted to post it before I left town. It contains a significant mistake.

The description of the visual styles problem is accurate. It is not new with Windows 10 1809, although 1809 seems to have changed the circumstances that trigger it.

The description of what is happening in TBird is accurate.

My mistake was in linking the two. When you hit the visual styles problem you generally get a failure on the CoCreateInstance call that creates the common item dialog. That is not what is happening here. I am getting an error on the call to Show the dialog.

This returns HRESULT 80070715. Thinking about his while away, I realized this breaks down to

  8 - application level failure
  007 - Win 32 error
  0715 - Resource Type Not Found.

This is not an error I would expect in production code, but it might come from a corrupted or mismatched dll. Maybe there was a problem in installing the 1809 update.

So the first things I did when I got back were to run a full virus scan (found nothing) and an sfc scan (found several bad dlls, including comdlg32). After the sfc repair, TBird now works.

To answer one question, I have not yet file a bug. But I will. As I said before, the code here take ANY failure during the CoCreateInstance or Show calls as though the user hit the Cancel button. The effect is that the user hits a menu entry to save or open a file and ... nothing at all happens. Not good. I will will file a bug.

But first, one more question, in a new thread.


On Thursday, July 4, 2019 at 9:38:26 PM UTC-7, Paul Schauble wrote:
> It didn’t get much notice, but I earlier reported that on Windows
> 10 v1809, Thunderbird 60.7.* cannot save a file. I had tried to
> save an image from an HTML email, save an attachment from the list
> at the bottom of an email, and to save an email from the File /
> Save As menu. All these fail in the same way: Nothing happens. In
> particular, no File Save dialog appears.
> I later discovered that TBird also cannot open a file to attach it
> to an email. Again, nothing visible happens.
> After getting nowhere with my requests, I attempted to build a
> release version of TBird with debugging information. So far I am
> unable to do this.
> But, I’m pretty good a low level debugging so I can tell you what
> is failing and probably why.
> I am testing by attempting to save a jpg image embedded in an HTML
> email by right clicking on the image and selecting Save Image As.
> The failure occurs in source file
> z:\task_1561018548\build\src\widget\windows\nsFilePicker.cpp,
> function nsFilePicker::ShowFilePicker at line 479. The call stack
> at the point is 
>   xul.dll!nsFilePicker::ShowFilePicker(const
>       nsTString & aInitialDir) Line 480	C++
>   xul.dll!nsFilePicker::ShowW(short * aReturnVal) Line 564	C++
>   xul.dll!nsBaseFilePicker::AsyncShowFilePicker::Run() Line 85	C++ 
>   xul.dll!nsThread::ProcessNextEvent(bool aMayWait, bool *aResult) Line 976 C++
> The code at the point of failure is 
> Line 479
>     if (FAILED(dialog->Show(adtw.get()))) {
>       dialog->Unadvise(mFDECookie);
>       return false;
> The variable "dialog" is a pointer to the COM object for the new
> Save File dialog. This call returns the HRESULT 80070715. 
> Instead of checking for the specific HRESULT that would be
> returned when the user hit the Cancel button,
> HRESULT_FROM_WIN32(ERROR_CANCELLED), the code is only looking for
> any failure HRESULT. The false return is passed back and the calling code
> just forgets about the save, assuming the user hit cancel.
> What I think is happening is that the new file dialogs require
> that visual styles are active and fail in various ways if they are
> not. I have built a sample Win32 application that calls the file
> save dialog, and returns the same HRESULT on the call to Show.
> It appears that Windows 10 version 1809 has broken the new dialog code
> in new and exiting ways. This worked in v1803.
> The Microsoft recommendation is that if the the object create or
> the Show calls return errors, the application code should fall
> back and use the Windows XP dialogs GetOpenFileName and
> GetSaveFileName. Very ugly, but better than a complete failure.
> I'm told this problem has existed with Windows Vista. I'm not
> holding my breath waiting for a proper fix.
> To complicate further, I'm also told that the XP dialogs have some
> of the functions broken in v1809.
> If I could build TBird, I would implement and test the fallback
> code. Since I can't, the most I can do is offer to test if someone
> else wants to undertake this fix. Or put the effort into helping me
> build the product.
> If I'm right about the underlying cause, you should be able to
> reproduce the problem in Windows 10 by setting a high contrast
> theme. This disables visual styles. When I get back next week,
> I'll set up VMs for 1803 and 1809 and test this. But probably
> someone else can test it before I can. 
>  ++PLS