TBird can't save *anything*, part 2

It didn=E2=80=99t 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=E2=80=99m 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=20
  xul.dll!nsFilePicker::ShowFilePicker(const
      nsTString<char16_t> & aInitialDir) Line 480	C++
  xul.dll!nsFilePicker::ShowW(short * aReturnVal) Line 564	C++
  xul.dll!nsBaseFilePicker::AsyncShowFilePicker::Run() Line 85	C++=20
  xul.dll!nsThread::ProcessNextEvent(bool aMayWait, bool *aResult) Line 976=
 C++

The code at the point of failure is=20

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.=20

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.=20

 ++PLS
0
Paul
7/5/2019 4:38:24 AM
mozilla.dev.apps.thunderbird 3433 articles. 0 followers. Post Follow

15 Replies
74 Views

Similar Articles

[PageSpeed] 40

I wonder if this kind of subtle low-level API failure or
semantic change in the recent Windows release might be the cause of very 
strange bug I have been seeing since my windows update about a month ago.

https://bugzilla.mozilla.org/show_bug.cgi?id=1559267
Deletion of a message does not get reflected in the display (even 
compaction and repairing the folder did not help).
(Actually, "deletion" operation is NOT invoked is better. I will change 
the title.)

There I see an error returned by a lower-level API mechanism:
2147500037
0x80004005

Since the error code is different, I believe Paul's problem has a 
different origin, though, as his analysis shows.
In my case, the call to lower-level API from the JS-side seems to return 
an error even without calling it somehow.

TIA


On 2019/07/05 13:38, 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<char16_t> & 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
> _______________________________________________
> dev-apps-thunderbird mailing list
> dev-apps-thunderbird@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-thunderbird


0
ISHIKAWA
7/5/2019 5:57:27 AM
To OP: since updating to win 10 1903, my FF cannot save downloads any longer. Sounds related. For example PDF from the Display tab.

To Ishikawa: with two Client PC for an imap Account i am seeing Problems with delete email States not propagating via imap to the other Client. Ca. Since TB 60. So they are deleted on one but not the other client. Related?
Klaus 
0
opto
7/5/2019 6:07:19 AM
On 2019/07/05 15:07, opto wrote:
> To OP: since updating to win 10 1903, my FF cannot save downloads any longer. Sounds related. For example PDF from the Display tab.
> 
> To Ishikawa: with two Client PC for an imap Account i am seeing Problems with delete email States not propagating via imap to the other Client. Ca. Since TB 60. So they are deleted on one but not the other client. Related?
> Klaus 
> 

The second problem seems to me it is more on the server-side problem (?),
but without digging deeper, I can't say for sure. At least in your case, the
deletion of the message happens in your TB client, correct?
In my case, the deletion does not take place at all (I am using POP3) and I
have already have the message in the local folder. I should be able to
delete it, but somehow, hitting the [delete] menu or button in a few places
ended up getting a bland error return without any indication of what is
wrong except for the mysterious exception with error code value (which is
NS_ERROR_FAILURE and is not helpful...) I have a suspicion that JS
interpreter is failing to call C++ entry point, but I have no idea why.

But it *IS* interesting to learn that there seem to be a few problems of
subtle change of low-level API behavior is causing problems.
0
ishikawa
7/5/2019 9:08:16 AM
On 2019/07/05 13:38, 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<char16_t> & 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
> 

So what you are saying is that, under the new build of  Windows10, TB's menu
handling code for file picker automatically fails and returns the
user-cancellation code so that
TB's mainline won't handle file save or file attachment?

Hmm...

Interesting. In my case, the [delete] function has not been callable for a
while, but
attaching file seems to work: OK, I have only tried dragging the files from
explorer list.
Have you tried to see if drag and drop works for file attachment.
If so, your mention of file picker failure is basically the cause of the
problem you face for attachment failure. (The underlying code is still
working if drag and drop works.)

Chiaki


0
ishikawa
7/5/2019 9:14:23 AM
Not quite what I'm saying. The call to open the file save dialog returns 0x=
 80070715. If the dialog opens, hitting the cancel button would return HRES=
ULT_FROM_WIN32(ERROR_CANCELLED) which I think is 0x800704C7

I am saying two things:
  1. The code in nsFilePicker does not distinguish these return codes. It t=
akes *any* failure HRESULT as a cancel. This could be worse, but differenti=
ating the cases and giving an error message for the 0x80070715 code would h=
ave saved me a lot of time. I have a thing about checking for specific retu=
rn codes.
  2. Something is wrong that causes the 80070715 code in the first place. I=
t seems to be affecting a small number of application on my machine and aff=
ecting TBird for a small number of there people. Some of the affected apps =
display a message giving the error code and it is the same one. And as with=
 TBird, it seem that all variations of the Common Item dialogs are affected=
; the apps can neither open a file nor save one.

    ++PLS


On Friday, July 5, 2019 at 2:14:30 AM UTC-7, ishikawa wrote:
> On 2019/07/05 13:38, Paul Schauble wrote:
> > It didn=E2=80=99t get much notice, but I earlier reported that on Windo=
ws
> > 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.
> >=20
> > I later discovered that TBird also cannot open a file to attach it
> > to an email. Again, nothing visible happens.
> >=20
> > 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.
> >=20
> > But, I=E2=80=99m pretty good a low level debugging so I can tell you wh=
at
> > is failing and probably why.
> >=20
> > 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.
> >=20
> > 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=20
> >   xul.dll!nsFilePicker::ShowFilePicker(const
> >       nsTString<char16_t> & aInitialDir) Line 480	C++
> >   xul.dll!nsFilePicker::ShowW(short * aReturnVal) Line 564	C++
> >   xul.dll!nsBaseFilePicker::AsyncShowFilePicker::Run() Line 85	C++=20
> >   xul.dll!nsThread::ProcessNextEvent(bool aMayWait, bool *aResult) Line=
 976 C++
> >=20
> > The code at the point of failure is=20
> >=20
> > Line 479
> >     if (FAILED(dialog->Show(adtw.get()))) {
> >       dialog->Unadvise(mFDECookie);
> >       return false;
> >=20
> > The variable "dialog" is a pointer to the COM object for the new
> > Save File dialog. This call returns the HRESULT 80070715.=20
> >=20
> > 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 co=
de
> > just forgets about the save, assuming the user hit cancel.
> >=20
> > 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.
> >=20
> > It appears that Windows 10 version 1809 has broken the new dialog code
> > in new and exiting ways. This worked in v1803.
> >=20
> > 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.
> >=20
> > To complicate further, I'm also told that the XP dialogs have some
> > of the functions broken in v1809.
> >=20
> > 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.
> >=20
> > 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.=20
> >=20
> >  ++PLS
> >=20
>=20
> So what you are saying is that, under the new build of  Windows10, TB's m=
enu
> handling code for file picker automatically fails and returns the
> user-cancellation code so that
> TB's mainline won't handle file save or file attachment?
>=20
> Hmm...
>=20
> Interesting. In my case, the [delete] function has not been callable for =
a
> while, but
> attaching file seems to work: OK, I have only tried dragging the files fr=
om
> explorer list.
> Have you tried to see if drag and drop works for file attachment.
> If so, your mention of file picker failure is basically the cause of the
> problem you face for attachment failure. (The underlying code is still
> working if drag and drop works.)
>=20
> Chiaki

0
Paul
7/5/2019 10:06:41 AM
On 2019/07/05 19:06, Paul Schauble wrote:
> Not quite what I'm saying. The call to open the file save dialog returns 0x 80070715. If the dialog opens, hitting the cancel button would return HRESULT_FROM_WIN32(ERROR_CANCELLED) which I think is 0x800704C7
> 
> I am saying two things:
>   1. The code in nsFilePicker does not distinguish these return codes. It takes *any* failure HRESULT as a cancel. This could be worse, but differentiating the cases and giving an error message for the 0x80070715 code would have saved me a lot of time. I have a thing about checking for specific return codes.
>   2. Something is wrong that causes the 80070715 code in the first place. It seems to be affecting a small number of application on my machine and affecting TBird for a small number of there people. Some of the affected apps display a message giving the error code and it is the same one. And as with TBird, it seem that all variations of the Common Item dialogs are affected; the apps can neither open a file nor save one.
> 
>     ++PLS
> 

Thank you for the clarification.

Have you filed a bugzilla on this?

After detailed analysis of yours,
I am quite sure someone knowledgeable about Windows 10 can fix this issue in
a short time once this gets proper attention from developers.
It is a pity that this code seems to live in the TB-only portion.
If this is a shared code between mozilla-central, the bug would have been
eradicated much sooner...



Chiaki


> 
> On Friday, July 5, 2019 at 2:14:30 AM UTC-7, ishikawa wrote:
>> On 2019/07/05 13:38, 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<char16_t> & 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
>>>
>>
>> So what you are saying is that, under the new build of  Windows10, TB's menu
>> handling code for file picker automatically fails and returns the
>> user-cancellation code so that
>> TB's mainline won't handle file save or file attachment?
>>
>> Hmm...
>>
>> Interesting. In my case, the [delete] function has not been callable for a
>> while, but
>> attaching file seems to work: OK, I have only tried dragging the files from
>> explorer list.
>> Have you tried to see if drag and drop works for file attachment.
>> If so, your mention of file picker failure is basically the cause of the
>> problem you face for attachment failure. (The underlying code is still
>> working if drag and drop works.)
>>
>> Chiaki
> 

0
ishikawa
7/5/2019 10:48:21 AM
On 7/5/19 12:38 AM, Paul Schauble wrote:
> It didn=E2=80=99t get much notice, but I earlier reported that on Windo=
ws
> 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.
>=20
> I later discovered that TBird also cannot open a file to attach it
> to an email. Again, nothing visible happens.

No problem here using TB 60.7.2 on Ubuntu 18.04.2 Linux.

Saved your post and an image

Will be testing on Windows 10 shortly. Stay tuned.



--=20
OS: Ubuntu Linux 18.04LTS - Gnome Desktop
https://www.thunderbird.net/en-US/get-involved/
Good job keeping those airports safe during the Revolutionary War=20
Continental Army!

0
WaltS48
7/5/2019 2:52:02 PM
On 7/5/2019 12:38 AM, 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.

Again, no problem here using  Mozilla/5.0 (Windows NT 10.0; WOW64; 
rv:60.0) Gecko/20100101 Thunderbird/60.7.2.
0
WaltS48
7/5/2019 3:31:28 PM
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--0OE0qkUrBHQTP8E83x7RqdoInrxMsmkC0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 2019-07-05 at 11:31, WaltS48 wrote:

> On 7/5/2019 12:38 AM, Paul Schauble wrote:
>=20
>> It didn=E2=80=99t get much notice, but I earlier reported that on Wind=
ows=20
>> 10 v1809, Thunderbird 60.7.* cannot save a file. I had tried to=20
>> save an image from an HTML email, save an attachment from the list=20
>> at the bottom of an email, and to save an email from the File /=20
>> Save As menu. All these fail in the same way: Nothing happens. In=20
>> particular, no File Save dialog appears.
>>=20
>> I later discovered that TBird also cannot open a file to attach it=20
>> to an email. Again, nothing visible happens.
>=20
> Again, no problem here using  Mozilla/5.0 (Windows NT 10.0; WOW64;=20
> rv:60.0) Gecko/20100101 Thunderbird/60.7.2.

What Windows 10 version? Per the original post, the error would only be
expected to occur on 1809 or later. That level of OS-version information
doesn't seem to be provided in the version string you gave.

--=20
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw


--0OE0qkUrBHQTP8E83x7RqdoInrxMsmkC0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEJCOqsZEc2qVC44pUBKk1jTQoMmsFAl0fb70ACgkQBKk1jTQo
MmsN1w//YTYlLhCqxjfFNxeV7HrmzT/WYmycJIN3pabz8nIvPik5pkdjhmxN1Nb/
28wpbbT0qnsA6tqTZErTvoJNLIDuHUut+BablCMZ/dAbvx90D51tUy9MTx9KPW0h
q1yLUX4RTEQAtuTEvzMjOv/FvIWIwVYY0wMyUEBKHoFYUsDeOE3So2d8ou2BBGgB
xEELwLk9T1P7WpeNb0LAgkgpiN3qTL50R6QjW+2FfdZ0GZyDUEdM+bZ9jJM6SYbK
XjmAkIOTFtV5nOWGBSV1PkOkC/mkw4Ezw+UQikVtco85gQzJ9TERkWgZZnsdhiRS
JY4Yz3GY95zXgMff93a9zgfT9OLEQjtOXzOhvdjG/oXQKxKr3221SSR6giw2z1Pq
A0dtbfpsKnlJRsMZLejZgpr+OFNsit2ccjPZmoEMM57EqFKUMM+TeM9YDbh7g++U
vZuORgAH9gOqUiAExUXgEz2ERm8MOPa8nCQvAy6DxhVKlIFB4Qbx3DLQ4lp/WFxM
Jm1FmGCjMy2DL8wWsZmxk8wvBxAQNMhVaMuBf05JVX5fZzeZq+Io4t9n2RM/Dg5+
fCTdQ0YNTlkLB7bNwd7ooYtPKlLPibW9XsL+p66gqDf5DbJIs+bJaUstXH5nOwow
YIdUFDeitRv9uj8xUC4k6en2uNaReLJ8z624Jac9Bd7Abl8EtEE=
=CpZo
-----END PGP SIGNATURE-----

--0OE0qkUrBHQTP8E83x7RqdoInrxMsmkC0--
0
The
7/5/2019 3:41:49 PM
On 05.07.2019 17:41, The Wanderer wrote:
> On 2019-07-05 at 11:31, WaltS48 wrote:
> 
>> On 7/5/2019 12:38 AM, 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.
>> 
>> Again, no problem here using  Mozilla/5.0 (Windows NT 10.0; WOW64; 
>> rv:60.0) Gecko/20100101 Thunderbird/60.7.2.
> 
> What Windows 10 version? Per the original post, the error would only be
> expected to occur on 1809 or later. That level of OS-version information
> doesn't seem to be provided in the version string you gave.

No such problems here with Windows 10 1903 and TB 60.7.2.

Richard
0
Richard
7/5/2019 3:53:10 PM
On 7/5/19 11:41 AM, The Wanderer wrote:
> On 2019-07-05 at 11:31, WaltS48 wrote:
> 
>> On 7/5/2019 12:38 AM, 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.
>>
>> Again, no problem here using  Mozilla/5.0 (Windows NT 10.0; WOW64;
>> rv:60.0) Gecko/20100101 Thunderbird/60.7.2.
> 
> What Windows 10 version? Per the original post, the error would only be
> expected to occur on 1809 or later. That level of OS-version information
> doesn't seem to be provided in the version string you gave.
> 

1809

-- 
OS: Ubuntu Linux 18.04LTS - Gnome Desktop
https://www.thunderbird.net/en-US/get-involved/
Good job keeping those airports safe during the Revolutionary War 
Continental Army!
0
WaltS48
7/5/2019 5:41:50 PM
I am curious.

What locale of windows do people use?

I use Japanese version of Windows if that matters and have begun noticing
that message delete function from Javascript fails due to mysterious
exception all the time on my Windows 10 installation ever since the
automatic upgrade last month.
I checked again this morning and still "delete" does not work.

TIA

On 2019/07/06 2:41, WaltS48 wrote:
> On 7/5/19 11:41 AM, The Wanderer wrote:
>> On 2019-07-05 at 11:31, WaltS48 wrote:
>>
>>> On 7/5/2019 12:38 AM, 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.
>>>
>>> Again, no problem here using  Mozilla/5.0 (Windows NT 10.0; WOW64;
>>> rv:60.0) Gecko/20100101 Thunderbird/60.7.2.
>>
>> What Windows 10 version? Per the original post, the error would only be
>> expected to occur on 1809 or later. That level of OS-version information
>> doesn't seem to be provided in the version string you gave.
>>
> 
> 1809
> 

0
ishikawa
7/8/2019 1:42:40 AM
On 7/7/19 9:42 PM, ishikawa wrote:
> I am curious.
> 
> What locale of windows do people use?
> 
> I use Japanese version of Windows if that matters and have begun noticing
> that message delete function from Javascript fails due to mysterious
> exception all the time on my Windows 10 installation ever since the
> automatic upgrade last month.
> I checked again this morning and still "delete" does not work.
> 
> TIA

I use the English (United States) Home version.

> 
> On 2019/07/06 2:41, WaltS48 wrote:
>> On 7/5/19 11:41 AM, The Wanderer wrote:
>>> On 2019-07-05 at 11:31, WaltS48 wrote:
>>>
>>>> On 7/5/2019 12:38 AM, 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.
>>>>
>>>> Again, no problem here using  Mozilla/5.0 (Windows NT 10.0; WOW64;
>>>> rv:60.0) Gecko/20100101 Thunderbird/60.7.2.
>>>
>>> What Windows 10 version? Per the original post, the error would only be
>>> expected to occur on 1809 or later. That level of OS-version information
>>> doesn't seem to be provided in the version string you gave.
>>>
>>
>> 1809
>>
> 


-- 
OS: Ubuntu Linux 18.04LTS - Gnome Desktop
https://www.thunderbird.net/en-US/get-involved/
Good job keeping those airports safe during the Revolutionary War 
Continental Army!
0
WaltS48
7/8/2019 1:58:34 PM
I am back from vacation.=20

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

The description of the visual styles problem is accurate. It is not new wit=
h Windows 10 1809, although 1809 seems to have changed the circumstances th=
at 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 y=
ou generally get a failure on the CoCreateInstance call that creates the co=
mmon 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 th=
is 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 f=
rom 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 (fo=
und 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 be=
fore, the code here take ANY failure during the CoCreateInstance or Show ca=
lls as though the user hit the Cancel button. The effect is that the user h=
its 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.

  Thanks,
    ++PLS

On Thursday, July 4, 2019 at 9:38:26 PM UTC-7, Paul Schauble wrote:
> It didn=E2=80=99t 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.
>=20
> I later discovered that TBird also cannot open a file to attach it
> to an email. Again, nothing visible happens.
>=20
> 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.
>=20
> But, I=E2=80=99m pretty good a low level debugging so I can tell you what
> is failing and probably why.
>=20
> 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.
>=20
> 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=20
>   xul.dll!nsFilePicker::ShowFilePicker(const
>       nsTString<char16_t> & aInitialDir) Line 480	C++
>   xul.dll!nsFilePicker::ShowW(short * aReturnVal) Line 564	C++
>   xul.dll!nsBaseFilePicker::AsyncShowFilePicker::Run() Line 85	C++=20
>   xul.dll!nsThread::ProcessNextEvent(bool aMayWait, bool *aResult) Line 9=
76 C++
>=20
> The code at the point of failure is=20
>=20
> Line 479
>     if (FAILED(dialog->Show(adtw.get()))) {
>       dialog->Unadvise(mFDECookie);
>       return false;
>=20
> The variable "dialog" is a pointer to the COM object for the new
> Save File dialog. This call returns the HRESULT 80070715.=20
>=20
> 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.
>=20
> 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.
>=20
> It appears that Windows 10 version 1809 has broken the new dialog code
> in new and exiting ways. This worked in v1803.
>=20
> 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.
>=20
> To complicate further, I'm also told that the XP dialogs have some
> of the functions broken in v1809.
>=20
> 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.
>=20
> 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.=20
>=20
>  ++PLS

0
Paul
7/14/2019 2:05:42 AM
Bug 1567066 is filed.

    ++PLS

On Saturday, July 13, 2019 at 7:05:43 PM UTC-7, Paul Schauble wrote:
> I am back from vacation.=20
>=20
> I must apologize. My initial post was rushed since I wanted to post it be=
fore I left town. It contains a significant mistake.
>=20
> The description of the visual styles problem is accurate. It is not new w=
ith Windows 10 1809, although 1809 seems to have changed the circumstances =
that trigger it.
>=20
> The description of what is happening in TBird is accurate.
>=20
> 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 err=
or on the call to Show the dialog.
>=20
> This returns HRESULT 80070715. Thinking about his while away, I realized =
this breaks down to
>=20
>   8 - application level failure
>   007 - Win 32 error
>   0715 - Resource Type Not Found.
>=20
> 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 installin=
g the 1809 update.
>=20
> 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.
>=20
> 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. N=
ot good. I will will file a bug.
>=20
> But first, one more question, in a new thread.
>=20
>   Thanks,
>     ++PLS
>=20
> On Thursday, July 4, 2019 at 9:38:26 PM UTC-7, Paul Schauble wrote:
> > It didn=E2=80=99t get much notice, but I earlier reported that on Windo=
ws
> > 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.
> >=20
> > I later discovered that TBird also cannot open a file to attach it
> > to an email. Again, nothing visible happens.
> >=20
> > 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.
> >=20
> > But, I=E2=80=99m pretty good a low level debugging so I can tell you wh=
at
> > is failing and probably why.
> >=20
> > 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.
> >=20
> > 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=20
> >   xul.dll!nsFilePicker::ShowFilePicker(const
> >       nsTString<char16_t> & aInitialDir) Line 480	C++
> >   xul.dll!nsFilePicker::ShowW(short * aReturnVal) Line 564	C++
> >   xul.dll!nsBaseFilePicker::AsyncShowFilePicker::Run() Line 85	C++=20
> >   xul.dll!nsThread::ProcessNextEvent(bool aMayWait, bool *aResult) Line=
 976 C++
> >=20
> > The code at the point of failure is=20
> >=20
> > Line 479
> >     if (FAILED(dialog->Show(adtw.get()))) {
> >       dialog->Unadvise(mFDECookie);
> >       return false;
> >=20
> > The variable "dialog" is a pointer to the COM object for the new
> > Save File dialog. This call returns the HRESULT 80070715.=20
> >=20
> > 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 co=
de
> > just forgets about the save, assuming the user hit cancel.
> >=20
> > 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.
> >=20
> > It appears that Windows 10 version 1809 has broken the new dialog code
> > in new and exiting ways. This worked in v1803.
> >=20
> > 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.
> >=20
> > To complicate further, I'm also told that the XP dialogs have some
> > of the functions broken in v1809.
> >=20
> > 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.
> >=20
> > 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.=20
> >=20
> >  ++PLS

0
Paul
7/18/2019 5:46:23 AM
Reply: