1786988 - All menu items of the HELP menu become disabled (greyed out) after sending a message (until restart of TB) [Mac]

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect, P2)

Description

[Antony]

Once a message is sent, reply fwd or new message, the options in the HELP menu become greyed out. Only way to recover is to restart TB

Comment 1

[Wayne Mery (:wsmwk)]

per Antony's email this is 105.0b1.
Not reproducing for me on Mac 10.15

Comment 2

[Antony]

i checked back to 103.0 and same issue... did not think to look when using 103.

Maybe has something to do with macOS version then, if Wayne not getting same issue on 10.15 as I am on 12.5

Back on 105.0b1 and still same issue,

Comment 3

[Antony]

Attachment: Screenshot 2022-08-28 at 12.52.25.png

Error log after restart, Help options fine until I send an email then they are greyed out

email sent at 12.50.57 - right at bottom of screen shot

Comment 4

[Antony]

was able to go into troubleshooting mode 1st time but issue was sstill apparent. Tried to go back to TS mode to record error console, but now TB hangs trying to open the accounts or connect!
Have a copy of the apple dump if useful

Comment 5

[Antony]

Cannot get back into Trouble mode, even after a reboot. TB cannot seem to find the server for any of my accounts....
Appreciate a diif issue but maybe linked

Comment 6

[Antony]

updated to 105.0b2 - still same issue with the Help menu options, and unable to use Troubleshooting mode as it hanges on load trying to connect to the email servers

Comment 7

[Antony]

now on 106.0b1 and macOS 12.6 now
Issue still evident

Comment 8

[Rob Lemley [:rjl]]

I do see this with 106.0b5 and macOS 12.4. I'm at a loss as to what's going on though. The menu remains active until a message is sent, so apparently something in that process is disabling it and not re-enabling.

Comment 9

[Magnus Melin [:mkmelin]]

Look for disableonsend. But I don't see that touching the help menu

Comment 10

[Wayne Mery (:wsmwk)]

Troubleshoot mode helped for https://support.mozilla.org/en-US/questions/1392231

Comment 11

[Thomas D. (:thomas8)]

Confirming also for macOS Monterey 12.6, 102.4.2 (64-bit).
Having the entire help menu disabled until restarting TB looks like a regular bug which we should fix.

Comment 13

[Wayne Mery (:wsmwk)]

And presumably a regression. If someone can reproduce somewhat reliably, please have a go at https://mozilla.github.io/mozregression/

Comment 14

[Antony]

So, updated to TB108.0b1 also on Ventura 13.0.1 macOS en-GB, still same issue as reported at start

Comment 15

[Antony]

(In reply to Wayne Mery (:wsmwk) from comment #13)

And presumably a regression. If someone can reproduce somewhat reliably, please have a go at https://mozilla.github.io/mozregression/

I will run mozregression and see what it finds, prob is not sure how far back to go to when the bug started

Got the GUI but it seems to weant to load Firefox and Not TB, any ideas?

Comment 16

[Antony]

Okay, went back to 100, all good, ascertained that somewhere between 102.0b4 and full 102 release there was a change the caused this issue

Will try to narrow further with the regerssion ttol,- sometimes manually works better

Try to do with mozregression but keeps erroring after loading, reports the app is damage - must be the mac security not allowing progress error is -9

See new snapshot

The issue came up with 102.0b7, was fine with beta6

Comment 17

[Antony]

Attachment: Screenshot 2022-11-15 at 20.39.25.png

Comment 18

[Thomas D. (:thomas8)]

Attachment: Screenshot: mozregression output

Hmmmm. I ran mozregression for comm-central testing for this bug on macOS Monterey 12.6 , but the outcome doesn't look like the culprit. So either I did something wrong, or something went wrong.

Bug 1774529 - Add icons.css to Account Manager. r=darktrojan
Differential Revision: https://phabricator.services.mozilla.com/D149498
pushshlog_url: https://hg.mozilla.org/comm-central/pushloghtml?fromchange=5bcd2bef8808cdc138782e5be0962dbb9e93260a&tochange=2033c8d16c01f9becd0e8d7c5c4047b140aa7dbd
repo_name: comm-central

Comment 19

[Antony]

(In reply to Thomas D. (:thomas8) from comment #18)

Created attachment 9303793 [details]
Screenshot: mozregression output

Hmmmm. I ran mozregression for comm-central testing for this bug on macOS Monterey 12.6 , but the outcome cannot be the culprit. So either I did something wrong, or something went wrong.

Bug 1774529 - Add icons.css to Account Manager. r=darktrojan
Differential Revision: https://phabricator.services.mozilla.com/D149498
pushshlog_url: https://hg.mozilla.org/comm-central/pushloghtml?fromchange=5bcd2bef8808cdc138782e5be0962dbb9e93260a&tochange=2033c8d16c01f9becd0e8d7c5c4047b140aa7dbd
repo_name: comm-central

Thomas, what setup for mozregression did you use as I could not get mine to complete (I dont think) as you can see by my screen shot
As I note above the HELP menu is fine in beta6 but not in beta7 for 102.0

Comment 20

[Thomas D. (:thomas8)]

Alice, I think this needs you as our regression range expert (that's if you're willing and can afford the time - much appreciated!).
This bug is filed only against macOS. I ran mozregression, but I don't think the outcome is right for this bug (see comment 18). Maybe you'll get something better?

(In reply to Antony from comment #19)

Thomas, what setup for mozregression did you use as I could not get mine to complete (I dont think) as you can see by my screen shot
As I note above the HELP menu is fine in beta6 but not in beta7 for 102.0

According to Thunderbird's shared calendar:
102.0b6 was released on 15-06-2022. I chose 2022-05-01 as start date.
102.0b7 was released on 17-06-2022. So I chose 2022-06-18 as end date. You can see the resulting actual dates tested by mozregression in my screenshot.
Product: Thunderbird
Release-channel: comm-central (as I don't expect the breakage to come from Beta specifically, so it should be Daily).
Profile: reuse (with no initial profile specified, so I had to set up an email with the first run, but then it worked well).

One round was skipped (see yellow in screenshot), don't know why. It went through, but I don't think the outcome (see comment 18) is helpful/correct. If someone knows more, I'll be happy to learn.

Comment 21

[Alice0775 White]

the options in the HELP menu

What is the options?

Comment 22

[Antony]

Attachment: 1668718674084.JPEG

Comment 23

[Antony]

(In reply to Alice0775 White from comment #21)

the options in the HELP menu
What is the options?

The sub items that are under the HELP menu - see snapshot posted now with similar timeslot as this reply

Had to take it with the fone!!! As you can see in the jpg the submenu Option items are greyed out - a restart restores them, sending an email sets them grey again as in the attachment

Comment 24

[Alice0775 White]

(In reply to Antony from comment #23)

(In reply to Alice0775 White from comment #21)

the options in the HELP menu
What is the options?

The sub items that are under the HELP menu - see snapshot posted now with similar timeslot as this reply

Had to take it with the fone!!! As you can see in the jpg the submenu Option items are greyed out - a restart restores them, sending an email sets them grey again as in the attachment

Thank you.
Oh this was MacOS only. I have missed it.
I dont have Mac.

However, From screenshot of comment#18,
The regression window is
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=10534776b797c96cb581dca88d160a668cce84e3&tochange=d28b8c3f269dffd2c413145de32d7d81307d85a9

and related m-c range is
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0e44540919cda05e29992605143ca7a7b6982926&tochange=1c45ab9d8ec1596f931df2a1a91795c2dca22b5b

Comment 25

[Thomas D. (:thomas8)]

(In reply to Alice0775 White from comment #24)

However, From screenshot of comment#18,
The regression window is... [snip]

Thank you very much Alice!

In the comm-central regression range, afasics the only thing directly about hiding stuff when sending is
https://phabricator.services.mozilla.com/D149249 (Bug 1774123).

I am still baffled that this bug is only happening on macOS. Could it be related to that Search menu which macOS seems to inject as first menuitem into the Help menu?

Comment 26

[Antony]

(In reply to Thomas D. (:thomas8) from comment #20)

Alice, I think this needs you as our regression range expert (that's if you're willing and can afford the time - much appreciated!).
This bug is filed only against macOS. I ran mozregression, but I don't think the outcome is right for this bug (see comment 18). Maybe you'll get something better?

(In reply to Antony from comment #19)

Thomas, what setup for mozregression did you use as I could not get mine to complete (I dont think) as you can see by my screen shot
As I note above the HELP menu is fine in beta6 but not in beta7 for 102.0

According to Thunderbird's shared calendar:
102.0b6 was released on 15-06-2022. I chose 2022-05-01 as start date.
102.0b7 was released on 17-06-2022. So I chose 2022-06-18 as end date. You can see the resulting actual dates tested by mozregression in my screenshot.
Product: Thunderbird
Release-channel: comm-central (as I don't expect the breakage to come from Beta specifically, so it should be Daily).
Profile: reuse (with no initial profile specified, so I had to set up an email with the first run, but then it worked well).

One round was skipped (see yellow in screenshot), don't know why. It went through, but I don't think the outcome (see comment 18) is helpful/correct. If someone knows more, I'll be happy to learn.

Thanks Thomas
No idea as to why mine fails and does not report, werror is -9, whatever that means. But permissions should be fine and not prevent the run, unless some issue with the install of the app
Does the infor from Alice make anyone the wiser? I tried to scan thru the changes but an expert what so ever, so could not see anything that might cause the issue. I can move emails around from one email box to another and foilder to another, but as soon as then SEND is pressed, then Bingo goes the Help menu

Comment 27

[Antony]

(In reply to Thomas D. (:thomas8) from comment #25)

(In reply to Alice0775 White from comment #24)

However, From screenshot of comment#18,
The regression window is... [snip]

Thank you very much Alice!

In the comm-central regression range, afasics the only thing directly about hiding stuff when sending is
https://phabricator.services.mozilla.com/D149249 (Bug 1774123).

I am still baffled that this bug is only happening on macOS. Could it be related to that Search menu which macOS seems to inject as first menuitem into the Help menu?

---I am still baffled that this bug is only happening on macOS. Could it be related to that Search menu which macOS seems to inject as first menuitem into the Help menu?

• was that happening in build 102.0b6 and before or just recent?
• Has it been confirmed that this is NOT happening on Windows or Linux platforms?
  Only seems to happen when SEND is actioned

Comment 28

[Magnus Melin [:mkmelin]]

Can you reproduce this Help | Troubleshoot mode? Seem comment 1, Hold Shift during startup.
The functionality that enables/disables is updateAllItems(), but that is only loaded for the compose window, so no idea how that could affect the main window.

Comment 29

[Antony]

Might be worth exploring what actions in TB would "grey out" the HELP menu submenus - or what cricumstances, situations

(In reply to Magnus Melin [:mkmelin] from comment #28)

Can you reproduce this Help | Troubleshoot mode? Seem comment 1, Hold Shift during startup.
The functionality that enables/disables is updateAllItems(), but that is only loaded for the compose window, so no idea how that could affect the main window.

I'll have a go, as tried this before and had issues with activating the Troubleshoot mode - see comments 4 and 5

Comment 30

[Antony]

Attachment: Screenshot 2022-11-17 at 23.19.30.png

Comment 31

[Antony]

Ran troubleshoot mode - issue still apparent

Took snap of error log for the time of send, see laest file add above

Comment 32

[Antony]

Attachment: Errorlog afger Troubleshoot mode restart with Shift Key held.png

Comment 33

[Magnus Melin [:mkmelin]]

As so you're running beta.
I see a problem, and a fix we should make. Not sure it will resolve the base problem.

Comment 34

[Magnus Melin [:mkmelin]]

Attachment: Bug 1786988 - Port bug 1642138 to Thunderbird: Improve integration with the macOS-level Window menu handling to unlock built-in OS functionality such as tiling of windows.. r=#thunderbird-reviewers

Port of https://hg.mozilla.org/mozilla-central/rev/46538d8cbaf17ea3843c7e1c0d9fc4b737207936

Comment 35

[Antony]

(In reply to Magnus Melin [:mkmelin] from comment #33)

As so you're running beta.
I see a problem, and a fix we should make. Not sure it will resolve the base problem.

running beta - yes!
see a prob - cool bananas, hope it does fix, am ready to test when fix released

Comment 36

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/2b3057e1c7bc
Port bug 1642138 to Thunderbird: Improve integration with the macOS-level Window menu handling to unlock built-in OS functionality such as tiling of windows.. r=rjl

Comment 37

[Wayne Mery (:wsmwk)]

Antony, are you able to test daily build, to see if it still reproduces?

Comment 38

[Wayne Mery (:wsmwk)]

Is there a specific reason you marked version 102 as not affected?

Version 102 has a similar problem, according to bug 1798874, Mac with Thunderbird 102.3.1 and others.
Note - bug 1642138 has regressions reported against it.

Comment 39

[Wayne Mery (:wsmwk)]

This is especially problematic because in some cases it (loss of Help > troubleshoot mode for example) hinders resolving other problems.

Comment 40

[Antony]

(In reply to Wayne Mery (:wsmwk) from comment #37)

Antony, are you able to test daily build, to see if it still reproduces?

Yes, I have been looking to see if there has been a daily to test

I looked at the FTP for the Daily and saw 109.0a1 buildID=20221125103401, and ran that... still have the bug - however, understand if I jumoped the gun here !!! :-)

Comment 41

[Antony]

(In reply to Wayne Mery (:wsmwk) from comment #39)

This is especially problematic because in some cases it (loss of Help > troubleshoot mode for example) hinders resolving other problems.

It is a prob cos then cannot run Troublesdhoot mode for one

Comment 42

[Antony]

(In reply to Wayne Mery (:wsmwk) from comment #38)

Is there a specific reason you marked version 102 as not affected?

Version 102 has a similar problem, according to bug 1798874, Mac with Thunderbird 102.3.1 and others.
Note - bug 1642138 has regressions reported against it.

Wayne, not sure if Q aimed at me - I am only reporting on the beta releases. No idea if the 102 pub release works, though if it is the same as was released after the 102.0.beta versions then it still fails, as the bug is a result of a change in 102.0b7 b6 was fine

Comment 43

[Antony]

(In reply to Wayne Mery (:wsmwk) from comment #38)

Is there a specific reason you marked version 102 as not affected?

Version 102 has a similar problem, according to bug 1798874, Mac with Thunderbird 102.3.1 and others.
Note - bug 1642138 has regressions reported against it.

I did reply to this already, but it got lost - Now i see it above this one!

So if Q aimed at me then I am only reporting on the beta releases. The bug appeared after 102.0b7, b6 was fine, as I regressed tested back to those versions (and even 102.0b1). If by 102 release you mean the Public release then I am not sure, unless that release is the same as the 102 final after the 7 betas we had. Then I would say that this 102 version also has the issue but `i cannot test easily.

Comment 44

[Antony]

Re Daily Test Q

Yes, I have been looking to see if there has been a daily to test

I looked at the FTP for the Daily and saw 109.0a1 buildID=20221125103401, and ran that... still have the bug - however, understand if I jumoped the gun here !!! :-)

Comment 45

[Magnus Melin [:mkmelin]]

Oh, I thought it was only beta.

Comment 46

[Antony]

let me know when there is a "daily" for the mac on FTP, I see there is an en-GB in the nightly for 26 Nov, the one on 25/11 didnot make any diff as noted above

Comment 47

[Antony]

so running 108.0b2 - issue still apparent

Comment 48

[Wayne Mery (:wsmwk)]

Happens in safe mode?
Anything different in error console?

Comment 49

[Wayne Mery (:wsmwk)]

And Firefox doesn't show similar problem?

Comment 50

[Antony]

(In reply to Wayne Mery (:wsmwk) from comment #49)

And Firefox doesn't show similar problem?

Looked at a way to test but as not sending emails from FF not sure how I can test!!! :-/

Comment 51

[Antony]

(In reply to Wayne Mery (:wsmwk) from comment #48)

Happens in safe mode?
Anything different in error console?

I'll recheck the SAFE as am sure looked at that, and then look at Error and let you know - in a few mins

Comment 52

[Antony]

(In reply to Antony from comment #51)

(In reply to Wayne Mery (:wsmwk) from comment #48)

Happens in safe mode?
Anything different in error console?

I'll recheck the SAFE as am sure looked at that, and then look at Error and let you know - in a few mins

If by SAFE mode you mean Troubleshooting (TS) - error still apparent when in TS mode

I just added 2 screenshots, 1st after fresh start BEFORE sending, the 2nd shows the extra lines in log AFTER sending email. This was doen in NORMAL mode

Comment 53

[Antony]

Attachment: Error log after restart B4 send.png

Comment 54

[Antony]

Attachment: Addition to Log after email send.png

Comment 55

[Richard Marti (:Paenglab)]

I looked into it why I don't see this. When I change mailnews.show_send_progress to the default true the menus are disabled after send. With setting to false it is always enabled.

So somehow this send progress dialog triggers this issue.

Antony, can you try again with setting the pref mailnews.show_send_progress to false?

Comment 56

[Antony]

Managed to find a way to test this bug under 102.5.1 release, that is out today

The problem exits with this release as well!!!(In reply to Richard Marti (:Paenglab) from comment #55)

I looked into it why I don't see this. When I change mailnews.show_send_progress to the default true the menus are disabled after send. With setting to false it is always enabled.

So somehow this send progress dialog triggers this issue.

Antony, can you try again with setting the pref mailnews.show_send_progress to false?

Will do that now with 102.5.1, then revert back to 108.0b2 and try again

Comment 57

[Antony]

(In reply to Richard Marti (:Paenglab) from comment #55)

I looked into it why I don't see this. When I change mailnews.show_send_progress to the default true the menus are disabled after send. With setting to false it is always enabled.

So somehow this send progress dialog triggers this issue.

Antony, can you try again with setting the pref mailnews.show_send_progress to false?

Just tested the above Pref change and IT WORKS for both versions - HELP menu Options back online -

cool bananas - tx Richard M

Odd that a Send email instruction would cause the HELP Options to grey because of this Pref being set to True!

Comment 58

[Wayne Mery (:wsmwk)]

Interesting findings.

I've been running with mailnews.show_send_progress = false forever, but I'm not having Help menu problems.

Comment 59

[Antony]

(In reply to Wayne Mery (:wsmwk) from comment #58)

Interesting findings.

I've been running with mailnews.show_send_progress = false forever, but I'm not having Help menu problems.

Set it to TRUE and reckon you will

So did you manually set to FALSE at some point, or has it always been that way? And if yes to either, why was mine, and Richard's (unless he just put to True to test) been set to TRUE?

There must have been something in the 102.0b7 release that changed my Pref setting then. Hard to check unless I can find the profile as it was when at 102.0b6

Or, something was changed that caussed the SEND command to "interact" with the "mailnews.show_send_progress" pref in such a way that whn TRUE it greys out the HELP Options

Under what circumstances or actions would the HELP menu Options be "greyed" anyway? That could give a clue as to why we have this bug

Comment 60

[Wayne Mery (:wsmwk)]

Reproducing for me required both mailnews.sendInBackground = false and mailnews.show_send_progress = true. Happened immediately.

Perhaps related
in getEncryptionFlags, gSendEncrypted=false, gSendSigned=false enigmailMsgComposeOverlay.js:1531:13
18:46:49.423
NS_ERROR_FAILURE: No directory for uri=jsaddrbook://history.sqlite AddrBookManager.jsm:272
getDirectory resource:///modules/AddrBookManager.jsm:272
_collectAddressesToAddressBook resource:///modules/MessageSend.jsm:1130
_deliverAsMail resource:///modules/MessageSend.jsm:1060
_deliverMessage resource:///modules/MessageSend.jsm:778
InterpretGeneratorResume self-hosted:1819
AsyncFunctionNext self-hosted:807

Comment 61

[Antony]

(In reply to Wayne Mery (:wsmwk) from comment #60)

Reproducing for me required both mailnews.sendInBackground = false and mailnews.show_send_progress = true. Happened immediately.

Perhaps related
in getEncryptionFlags, gSendEncrypted=false, gSendSigned=false enigmailMsgComposeOverlay.js:1531:13
18:46:49.423
NS_ERROR_FAILURE: No directory for uri=jsaddrbook://history.sqlite AddrBookManager.jsm:272
getDirectory resource:///modules/AddrBookManager.jsm:272
_collectAddressesToAddressBook resource:///modules/MessageSend.jsm:1130
_deliverAsMail resource:///modules/MessageSend.jsm:1060
_deliverMessage resource:///modules/MessageSend.jsm:778
InterpretGeneratorResume self-hosted:1819
AsyncFunctionNext self-hosted:807

For me: mailnews.sendInBackground = false is already set to FALSE, and mailnews.show_send_progress = true was TRUE at time when having the issue, now its set to FALSE (with the mailnews.sendInBackground = false both instances for the _progress setting), and do NOT have the issue

Wayne, If you restart TB and set the "mailnews.show_send_progress" back to FALSE, issue no longer happens. Its just whenthis parameter is TRUE

Comment 62

[Antony]

Now - if both parameters are set to TRUE, dont get the issue!!!!

So what on earth have these 2 params got to do with email send, as mailnews, or am I missing something?

Comment 63

[Wayne Mery (:wsmwk)]

Anyone able to confirm the regression range of comment 24 is accurate by manually installing the daily builds? (if it hasn't been done already)

Comment 64

[Antony]

(In reply to Wayne Mery (:wsmwk) from comment #63)

Anyone able to confirm the regression range of comment 24 is accurate by manually installing the daily builds? (if it hasn't been done already)

If someone can advise as to the builds and where to find in FTP I can give it a go

Comment 65

[Wayne Mery (:wsmwk)]

The date is June 16, so I think

• should work https://archive.mozilla.org/pub/thunderbird/nightly/2022/06/2022-06-16-10-10-02-comm-central/thunderbird-103.0a1.en-US.mac.dmg
• should fail https://archive.mozilla.org/pub/thunderbird/nightly/2022/06/2022-06-17-09-57-00-comm-central/thunderbird-103.0a1.en-US.mac.dmg

Comment 66

[Antony]

That's curious - how come release 103.0? Or is this how it works, 103 alpha is 102 beta, but that seems odd?
I'll give these a go later

Comment 67

[Wayne Mery (:wsmwk)]

See comment 24. Those patch landings are on comm-central which is nightly builds.

Comment 68

[Antony]

Attachment: About showing install version and HELP issue still apparent

Comment 69

[Antony]

https://archive.mozilla.org/pub/thunderbird/nightly/2022/06/2022-06-16-10-10-02-comm-central/thunderbird-103.0a1.en-US.mac.dmg

Ran this - see screenshot, as soon as I switch the parameter, mailnews.show_send_progress, back to true the issues re-emerges

Did not bother with the later daily!!!

Comment 70

[Wayne Mery (:wsmwk)]

Perhaps then I misjudged and the issue should not be present in https://archive.mozilla.org/pub/thunderbird/nightly/2022/06/2022-06-15-10-59-15-comm-central/thunderbird-103.0a1.en-US.mac.dmg

If that one also fails, then the regression range we are working with is wrong.

Comment 71

[Antony]

(In reply to Wayne Mery (:wsmwk) from comment #70)

Perhaps then I misjudged and the issue should not be present in https://archive.mozilla.org/pub/thunderbird/nightly/2022/06/2022-06-15-10-59-15-comm-central/thunderbird-103.0a1.en-US.mac.dmg

If that one also fails, then the regression range we are working with is wrong.

What is the range of nightlys that covered the change from 102.0b6 to 102.0b7 as its after the b7 release that the issue arises

Comment 72

[Wayne Mery (:wsmwk)]

102.0b7 pulls in https://mzl.la/3iFTzEn and perhaps dozens of mozilla-central patches.

Definitive confirmation of regression tends to be easier via nightly builds.

Comment 73

[Antony]

On reflection - what should these parameters be set to for TB to function correctly? If it is reasonable to set to "False" then there is no need to resolve further.
Maybe someone could advise as to the above

Comment 74

[Wayne Mery (:wsmwk)]

If the problem started in 102.0b7, attachment 9281196 [details] from bug 1774123 must be a suspect.
Antony, does the problem reproduce for you when using https://archive.mozilla.org/pub/thunderbird/nightly/2022/06/2022-06-17-22-46-13-comm-central/thunderbird-103.0a1.en-US.mac.dmg ?

Comment 75

[Antony]

Attachment: Screenshot 2022-12-27 at 11.56.59.png

showing the version after applying the nightly patch from Wayne - see other comment

Comment 76

[Antony]

(In reply to Wayne Mery (:wsmwk) from comment #74)

If the problem started in 102.0b7, attachment 9281196 [details] from bug 1774123 must be a suspect.
Antony, does the problem reproduce for you when using https://archive.mozilla.org/pub/thunderbird/nightly/2022/06/2022-06-17-22-46-13-comm-central/thunderbird-103.0a1.en-US.mac.dmg ?

Waybne - ran the nightly above and problem does reproduce when the parameter is set back to TRUE for the mailnews.show_send_progress

I posted a screen of the version above to confirm this is the expect version show after applying the "nightly"

NOTE: I set the parameter nack to TRUE after installing the nightly before sending an email. As asked before does this parameter need to FALSE to start or should work in TRUE state? If should be FALSE then do I need to test to see if the nightly sets it to TRUE inadvertently, and so cause the problem?

Comment 77

[Antony]

Maybe the only real way to test is to use the Prefs file from 102.0b6, so not corrupted, as maybe the manual swtiching is messing the results.

Mainly to see what state the mailnews.show parameter was at the time and did it get switched to TRUE by the nightly, when it should stay false to start

Comment 78

[Wayne Mery (:wsmwk)]

I doubt we need any further testing to show that this began with bug 1774123, or another patch in the immediate vicinity of June 17.

Comment 79

[Antony]

(In reply to Wayne Mery (:wsmwk) from comment #78)

I doubt we need any further testing to show that this began with bug 1774123, or another patch in the immediate vicinity of June 17.

what is interesting is that I remeber looking at the list of changes that took place at that time and this is the one that stood out as the likley culprit (if indeed it is)!

So - what should the mailnews.show parameter be set to for normal state - FALSE or TRUE?

Will there be a release to "remove" the particular change?

Comment 80

[Magnus Melin [:mkmelin]]

(In reply to Wayne Mery (:wsmwk) from comment #78)

I doubt we need any further testing to show that this began with bug 1774123, or another patch in the immediate vicinity of June 17.

Right. It needs someone with a Mac to debug what's going on here, backing out 9fd8ef760060 locally and checking how the preferences play into it all.

Comment 81

[Wayne Mery (:wsmwk)]

Thomas, can you tackle comment 80?

Comment 82

[Antony]

I can attempt to back out the patch if someone explains how and proivides the backout file

Comment 83

[Thomas D. (:thomas8)]

(In reply to Wayne Mery (:wsmwk) from comment #81)

Thomas, can you tackle comment 80?

Ok, this was a bit of a hassle for a staunch Windows user and Mac newcomer like myself. However ultimately, looks like I just kept shooting myself in the foot by forgetting to use -purgecaches when tweaking that single line of MsgComposeCommands.js in omni.ja. On the upside, I now have 'Visual Studio Code' installed on my Mac :-)

(In reply to Magnus Melin [:mkmelin] from comment #80)

(In reply to Wayne Mery (:wsmwk) from comment #78)

I doubt we need any further testing to show that this began with bug 1774123, or another patch in the immediate vicinity of June 17.
Right. It needs someone with a Mac to debug what's going on here, backing out 9fd8ef760060 locally and checking how the preferences play into it all.

Here's my findings:

• backing out 9fd8ef760060 from bug 1774123 locally fixes the problem of this bug (disabled help menu) regardless of the pref settings for mailnews.show_send_progress or mailnews.sendInBackground. The backout reverts "true" to true in this line.
• Setting mailnews.sendInBackground = true has the same net effect as setting mailnews.show_send_progress = false: both will prevent showing the send progress dialogue. It seems to be presence of the Send Progress dialogue which makes this fail when the above changeset isn't backed out.
• It's worth noting that Mac only ever shows a single main menu, which is different from Windows where each window (also composition) has its own main menu. So maybe the dialog getting focus somehow interferes with us getting to that generic menu.
• The associated functions like setDisabledState need some scrutiny around "true" (string) vs. true (boolean) and logic of the conditionals:

  function setDisabledState(aElement, aValue) {
    if ("disabled" in aElement) {
      aElement.disabled = aValue == "true";
    } else if (aValue == "") {
      aElement.removeAttribute("disabled");
    } else {
      aElement.setAttribute("disabled", aValue);
    }
  }

Imo, the else if is no-op, because you can only remove a disabled attribute which exists, but if it exists, we'll never get here because the if("disabled" in aElement) will catch that first.

Comment 84

[Thomas D. (:thomas8)]

(In reply to Thomas D. (:thomas8) from comment #83)

(In reply to Magnus Melin [:mkmelin] from comment #80)

(In reply to Wayne Mery (:wsmwk) from comment #78)

I doubt we need any further testing to show that this began with bug 1774123, or another patch in the immediate vicinity of June 17.
Right. It needs someone with a Mac to debug what's going on here, backing out 9fd8ef760060 locally and checking how the preferences play into it all.

Here's my findings: [snip]

Comment 85

[Magnus Melin [:mkmelin]]

I'm not sure where this goes wrong, but it seems this function can be greatly simplified. I'll attach a patch, please see if it works on mac

Comment 86

[Magnus Melin [:mkmelin]]

Attachment: Bug 1786988 - Ensure help menu items are enabled on macOS after sending a message. r=micahilbery,freaktechnik,mkmelin,#thunderbird-front-end-reviewers

Comment 87

[Richard Marti (:Paenglab)]

(In reply to Magnus Melin [:mkmelin] from comment #85)

I'm not sure where this goes wrong, but it seems this function can be greatly simplified. I'll attach a patch, please see if it works on mac

Unfortunately the Help menus are still disabled.

Comment 88

[Antony]

(In reply to Richard Marti (:Paenglab) from comment #87)

(In reply to Magnus Melin [:mkmelin] from comment #85)

I'm not sure where this goes wrong, but it seems this function can be greatly simplified. I'll attach a patch, please see if it works on mac

Unfortunately the Help menus are still disabled.

So Magnus's patch not working? I see in Phabricator there are two errors - are these significant?

Richard - did you run this already?

Comment 89

[Richard Marti (:Paenglab)]

(In reply to Antony from comment #88)

Richard - did you run this already?

Yes, that's why I replied with the negative result.

Comment 90

[Antony]

(In reply to Richard Marti (:Paenglab) from comment #89)

(In reply to Antony from comment #88)

Richard - did you run this already?

Yes, that's why I replied with the negative result.

I realised you must have done, so I know it looked like a stupid question. I aksed to confirm because phabricator is showing 2 errors and was checking in case your comment was ore related to the errors

Will these errors be causing the patch to fail?

Comment 91

[Richard Marti (:Paenglab)]

The errors don't affect the function. They are checks for a pretty code (here only because the lines are longer than 80 chars).

Comment 92

[Antony]

so where can I find the patch

Comment 93

[Richard Marti (:Paenglab)]

You have to self build. There are no builds with this patch. And it makes also sense as it doesn't work.

Comment 94

[Magnus Melin [:mkmelin]]

If you choose the compose window in the dev tools, and then run ToggleWindowLock(false);, does that enable the menus?

Comment 95

[Richard Marti (:Paenglab)]

Not sure if I did it correctly: After sending a message reopened the composer, selected it in in dev toolbox and entered the command in split console. I get a undefined and the menu is still disabled. No difference with and without your patch.

Comment 96

[Magnus Melin [:mkmelin]]

That sounds correct. On linux I can use ToggleWindowLock(true); and ToggleWindowLock(false); to toggle the disabled states. So this tells us it's not a missing call, but for some getting out of the disabled state that causes issues.

With 9fd8ef760060 backed out, does the disabling happen in the first place at all, for the menu?

Comment 97

[Richard Marti (:Paenglab)]

With 9fd8ef760060 backed out the menu stays enabled.

Comment 98

[Antony]

(In reply to Richard Marti (:Paenglab) from comment #97)

With 9fd8ef760060 backed out the menu stays enabled.

so can someone provide me with a patch so I can test as well, please? Thanks gents

Comment 99

[Magnus Melin [:mkmelin]]

Anthony, thanks for the offer to help. At the moment there is no patch that seems to work. (The non-working diff is downloadable from the D168753 phabricator link on top of the bug.)

Comment 100

[Magnus Melin [:mkmelin]]

Ok, so conclusions:

• bug 1774123 made disabling during send also work on mac
• the path to enable is not working on mac: the bug is in the code that should enable the menu again

Comment 101

[Magnus Melin [:mkmelin]]

Update the patch. Perhaps it works now...

Comment 102

[Antony]

(In reply to Magnus Melin [:mkmelin] from comment #101)

Update the patch. Perhaps it works now...

Cool - forgive the "dumbness" but what link do I use in phabricator for the patch?

Comment 103

[Magnus Melin [:mkmelin]]

There's a link "Download Raw Diff".

Comment 104

[Antony]

(In reply to Magnus Melin [:mkmelin] from comment #103)

There's a link "Download Raw Diff".

Thanks - and then? how is that supposed to be patched? I am not a s/w coder - just about everything else though (rofl)

Comment 105

[Magnus Melin [:mkmelin]]

https://developer.thunderbird.net/thunderbird-development/getting-started
If you're not set up for coding, there's no real way to patch it. You can test builds later if/when we land it.

Comment 106

[Antony]

Just loaded 111.0b3

I note that the main "top" menu bar Help options still impacted - not a problem.

What is interesting (though not checked previously) is that the Help option in the Drop Down Menu on the Toolbar does NOT get impacted, Options still available

Comment 107

[Magnus Melin [:mkmelin]]

Thomas, Richard, how's the latest iteration of the patch?

Comment 108

[Richard Marti (:Paenglab)]

(In reply to Magnus Melin [:mkmelin] from comment #107)

Thomas, Richard, how's the latest iteration of the patch?

Unfortunately still disabled menus after sending a message.

Comment 109

[Antony]

(In reply to Richard Marti (:Paenglab) from comment #108)

(In reply to Magnus Melin [:mkmelin] from comment #107)

Thomas, Richard, how's the latest iteration of the patch?

Unfortunately still disabled menus after sending a message.

the Help Options in the Toolbar Menu work, (the drop-down from the 3 bars on right side) just not the Top Bar Help Menu

Comment 110

[Thomas D. (:thomas8)]

(In reply to Magnus Melin [:mkmelin] from comment #107)

Thomas, Richard, how's the latest iteration of the patch?

The current patch has simpflified everything a lot, which is great. There's something wrong around the boolean attribute disabled as the patch may set disabled="false", which doesn't work as it will still be disabled as long as the attribute is still present, regardless of the attribute value. See my review comment.

• Do we know why trying to change the Help menu of composition, we end up changing the Help menu of the main 3-pane? It seems to have something to do with the Sending message... alert, because whenever the alert is blocked, bug does not occur.
• (How) is the help menu shared between 3-pane and composition?

Comment 111

[Magnus Melin [:mkmelin]]

It will all need someone to debug on a mac. (The WIP patch should make that easier.)

Comment 112

[Wayne Mery (:wsmwk)]

Sören, are you able to debug with the WIP patch, and propose any changes?

Comment 113

[Sören Hentzschel]

Sören, are you able to debug with the WIP patch, and propose any changes?

I don't have a build environment and I am currently on vacation so I won't have time to set this up until May 27 at the earliest. I also don't know if I could help at all, since I am not familiar with the Thunderbird code. But let me know if you still want me to take a look once I am back.

Comment 114

[Alessandro Castellani [:aleca]]

Assigning this to Elizabeth.
Can use the code currently in the WIP patch and bring this to completion?

Comment 115

[Elizabeth Mitchell]

Yes, I will look into fixing this.

Comment 116

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/5d87d0381771
Ensure help menu items are enabled on macOS after sending a message. r=micahilbery,freaktechnik,mkmelin

Comment 117

[Antony]

Still not fixed - got this on error console:

21:26:40.750 mailnews.smtp:
error { target: TCPSocket, isTrusted: true, name: "NetworkTimeoutError", message: "Network", errorCode: 2152398862, srcElement: TCPSocket, eventPhase: 0, bubbles: false, cancelable: false, returnValue: true, … }
SmtpClient.jsm:434:17
22:13:24.761
mailnews.smtp:
error { target: TCPSocket, isTrusted: true, name: "NetworkTimeoutError", message: "Network", errorCode: 2152398862, srcElement: TCPSocket, eventPhase: 0, bubbles: false, cancelable: false, returnValue: true, … }
SmtpClient.jsm:434:17
22:14:20.579
mailnews.smtp: Command failed: 421 omf07.hostedemail.com Error: timeout exceeded; currentAction=_actionIdle SmtpClient.jsm:514:19
_onCommand resource:///modules/SmtpClient.jsm:514
_parse resource:///modules/SmtpClient.jsm:360
_onData resource:///modules/SmtpClient.jsm:417
22:14:20.587
mailnews.send: Sending failed; An error occurred while sending mail: Outgoing server (SMTP) error. The server responded: omf07.hostedemail.com Error: timeout exceeded., exitCode=2153066732, originalMsgURI= MessageSend.jsm:362:32
fail resource:///modules/MessageSend.jsm:362
_deliveryExitProcessing resource:///modules/MessageSend.jsm:711
sendDeliveryCallback resource:///modules/MessageSend.jsm:765
OnStopRunningUrl resource:///modules/MessageSend.jsm:1424
onerror resource:///modules/SmtpService.jsm:195
_onNsError resource:///modules/SmtpClient.jsm:490
_actionIdle resource:///modules/SmtpClient.jsm:1113
_onCommand resource:///modules/SmtpClient.jsm:519
_parse resource:///modules/SmtpClient.jsm:360
_onData resource:///modules/SmtpClient.jsm:417
22:14:20.589 NS_ERROR_ABORT: Component returned failure code: 0x80004004 (NS_ERROR_ABORT) [nsIWindowWatcher.openWindow]

The menu is still greyed out - there was a mo when I thought twas fixed, on a fwd email, but then I checked with a new email and menu became grey again

Comment 118

[Elizabeth Mitchell]

(In reply to Antony from comment #117)

Still not fixed - got this on error console:

What version of Thunderbird are you using? What operating system are you using?

Comment 119

[Elizabeth Mitchell]

Patch D168753 was added to 116 (when it was trunk).

This has not been uplifted to the current beta or upcoming ESR candidate.

I will test this again to make sure it is working correctly and request uplift.

Comment 120

[Elizabeth Mitchell]

(In reply to Elizabeth Mitchell from comment #118)

(In reply to Antony from comment #117)

Still not fixed - got this on error console:

What version of Thunderbird are you using? What operating system are you using?

Update: This is a macOS issue specifically dealing with the macOS application menu. Which version of macOS are you experiencing this problem with? My hope is that you are testing on a version that did not receive this uplift just yet. Thanks for testing this again.

Comment 121

[Elizabeth Mitchell]

Tested on macOS v13:

• 117.0a1 (2023-07-05) (64-bit) Daily (currently same as trunk) - Works as expected.
• 115.0b6 (64-bit) Beta - Does not work. Expected result because this has not been uplifted to 115 yet.

Comment 122

[Elizabeth Mitchell]

Comment on attachment 9315752 [details]
Bug 1786988 - Ensure help menu items are enabled on macOS after sending a message. r=micahilbery,freaktechnik,mkmelin,#thunderbird-front-end-reviewers

[Approval Request Comment]
Regression caused by (bug #): N/A
User impact if declined: Significant for macOS. Cannot reach help menu items after sending an email.
Testing completed (on c-c, etc.): Tested locally and on c-c. Has been in 116 daily for almost a week successfully.
Risk to taking this patch (and alternatives if risky): Low risk

[Approval Request Comment]
Regression caused by (bug #): N/A
User impact if declined: Significant for macOS. Cannot reach help menu items after sending an email.
Testing completed (on c-c, etc.): Tested locally and on c-c. Has been in 116 daily for almost a week successfully.
Risk to taking this patch (and alternatives if risky): Low risk

Comment 123

[Alessandro Castellani [:aleca]]

Antony, please don't reopen bugs independently.
Please, always report the TB version you're testing with.

Comment 124

[Rob Lemley [:rjl]]

Thunderbird 115.0:
https://hg.mozilla.org/releases/comm-esr115/rev/cade3fbfdeee

Comment 125

[Rob Lemley [:rjl]]

Comment on attachment 9315752 [details]
Bug 1786988 - Ensure help menu items are enabled on macOS after sending a message. r=micahilbery,freaktechnik,mkmelin,#thunderbird-front-end-reviewers

[Triage Comment]
Not needed on beta since the merge is passed. Approved for esr115 per Wayne.

Comment 126

[Antony]

(In reply to Elizabeth Mitchell from comment #118)

(In reply to Antony from comment #117)

Still not fixed - got this on error console:

What version of Thunderbird are you using? What operating system are you using?

115.0b6 on 13.4 macOS

Comment 127

[Antony]

(In reply to Alessandro Castellani [:aleca] from comment #123)

Antony, please don't reopen bugs independently.
Please, always report the TB version you're testing with.

I reopened as 1. I am the originator, 2. It is still not working so why was it closed

Comment 128

[Antony]

(In reply to Elizabeth Mitchell from comment #121)

Tested on macOS v13:

• 117.0a1 (2023-07-05) (64-bit) Daily (currently same as trunk) - Works as expected.
• 115.0b6 (64-bit) Beta - Does not work. Expected result because this has not been uplifted to 115 yet.

Hi Elizabeth, see above - got the impression from the reports above that the fix had been approved and uplifted to 115.0b6

Comment 129

[Antony]

(In reply to Elizabeth Mitchell from comment #122)

Comment on attachment 9315752 [details]
Bug 1786988 - Ensure help menu items are enabled on macOS after sending a message. r=micahilbery,freaktechnik,mkmelin,#thunderbird-front-end-reviewers

[Approval Request Comment]
Regression caused by (bug #): N/A
User impact if declined: Significant for macOS. Cannot reach help menu items after sending an email.
Testing completed (on c-c, etc.): Tested locally and on c-c. Has been in 116 daily for almost a week successfully.
Risk to taking this patch (and alternatives if risky): Low risk

[Approval Request Comment]
Regression caused by (bug #): N/A
User impact if declined: Significant for macOS. Cannot reach help menu items after sending an email.
Testing completed (on c-c, etc.): Tested locally and on c-c. Has been in 116 daily for almost a week successfully.
Risk to taking this patch (and alternatives if risky): Low risk

Want me to test as well by getting the 116 daily?

As much as the main menu HELP is an issue after a SEND, the HELP in the "burger" (if right terminology) menu works fine, always has - its always just been the one on the Title Menu bar

Comment 130

[Alessandro Castellani [:aleca]]

(In reply to Antony from comment #127)

(In reply to Alessandro Castellani [:aleca] from comment #123)

Antony, please don't reopen bugs independently.
Please, always report the TB version you're testing with.

I reopened as 1. I am the originator, 2. It is still not working so why was it closed

Because closing bugs and marking them as resolved is up to the core maintainers.
Fixes first land on trunk, then land on daily releases the day after, then get uplifted to beta or ESR if needed, so even if the bug is marked as closed that doesn't mean your current version will immediately get the fix.

Comment 131

[Antony]

(In reply to Alessandro Castellani [:aleca] from comment #130)

(In reply to Antony from comment #127)

(In reply to Alessandro Castellani [:aleca] from comment #123)

Antony, please don't reopen bugs independently.
Please, always report the TB version you're testing with.

I reopened as 1. I am the originator, 2. It is still not working so why was it closed

Because closing bugs and marking them as resolved is up to the core maintainers.
Fixes first land on trunk, then land on daily releases the day after, then get uplifted to beta or ESR if needed, so even if the bug is marked as closed that doesn't mean your current version will immediately get the fix.

Understood - do note, though, that you can always take it I am on the lateset beta, its my nature

so even if the bug is marked as closed that doesn't mean your current version will immediately get the fix.< - then surely you cannot mark it closed until it has been tested fully on a public release!!!

Comment 132

[Antony]

Loaded TB 116.0b12 en-GB on macOS 3.4 en-GB

So far tested Fwd and New email sends across 3 diff accounts (diff URLs) and the HELP menu is now working fine!!!!!

Comment 133

[Elizabeth Mitchell]

(In reply to Antony from comment #132)

Loaded TB 116.0b12 en-GB on macOS 3.4 en-GB

So far tested Fwd and New email sends across 3 diff accounts (diff URLs) and the HELP menu is now working fine!!!!!

Thanks for the update.