TBird can't save *anything*, part 2

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

TBird can't save *anything*, part 2

Paul Schauble
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
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

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

ISHIKAWA,chiaki
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
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-apps-thunderbird


_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

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

opto
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
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

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

ISHIKAWA,chiaki
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.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

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

ISHIKAWA,chiaki
In reply to this post by Paul Schauble
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


_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

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

Paul Schauble
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


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

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

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

ISHIKAWA,chiaki
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
>

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

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

WaltS48-9
In reply to this post by Paul Schauble
On 7/5/19 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.

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.



--
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!

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

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

WaltS48-9
In reply to this post by Paul Schauble
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.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

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

The Wanderer
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.

--
   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


_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Richard Marti
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
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

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

WaltS48-9
In reply to this post by The Wanderer
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!
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

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

ISHIKAWA,chiaki
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
>

_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

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

WaltS48-9
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!
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

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

Paul Schauble
In reply to this post by Paul Schauble
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.

  Thanks,
    ++PLS

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<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
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

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

Paul Schauble
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.
>
> 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.
>
>   Thanks,
>     ++PLS
>
> 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<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
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird