Closed Bug 1956258 Opened 1 year ago Closed 10 months ago

Can’t create new email/message when unified folder is enabled (if no default account was set)

Categories

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

Product:
Thunderbird
Component:
Mail Window Front End
Version:
Thunderbird 133
Type:
defect

Tracking

(thunderbird_esr128 unaffected, thunderbird_esr140+ fixed)

Status:
RESOLVED FIXED
Milestone:
142 Branch
Tracking Flags:
Tracking Status
thunderbird_esr128 --- unaffected
thunderbird_esr140 + fixed

People

(Reporter: joemcken64, Assigned: welpy-cw)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(1 file)

Bug 1956258 - Have default account getter auto-set a viable account. r=BenC,darktrojan
48 bytes, text/x-phabricator-request
corey
: approval-comm-esr140+
Details | Review

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:136.0) Gecko/20100101 Firefox/136.0

Steps to reproduce:

Enable “unified folders”, select a top-level unified folder (“Inbox”, “Drafts”, etc.) instead of a specific account, and try to create a new message (click “Write” button or type Ctrl+N).

Actual results:

Nothing happens. “Write” button and Ctrl+N are inoperable.
You must select a specific account under a unified folder for “Write”/Ctrl+N to open the message composer window.

Expected results:

You should be able to create a new email from unified folders as well as specific accounts, as was the behavior in previous versions.

Works for me with nightly build on Mac

Component: Untriaged → Mail Window Front End

Tested on
Windows 10 OS
Thunderbird beta 137.0b3 and also 128.8.0 esr

Set View > Folders > Unified
selected 'Unified Inbox'
Click on 'Write/New Message'
Write window opens and the default mail account email address is in the 'From'.

Works for me on both versions.
Not able to reproduce.

Please test : 'Help' > 'Troubleshoot Mode', click on 'Restart' and select 'Continue in Troubleshoot mode'
Report on results.
What addon extensions have you got installed whether enabled or not.

Flags: needinfo?(joemcken64)

Please test : 'Help' > 'Troubleshoot Mode', click on 'Restart' and select 'Continue in Troubleshoot mode'
Report on results.
What addon extensions have you got installed whether enabled or not.

Just tested with Troubleshoot Mode, which completely reset my Thunderbird’s layout.
When using unified folders, both the “+ New Message” and “Write” buttons (I added the latter using the Customize menu) worked just fine, regardless of what is selected in the sidebar.
After disabling Troubleshoot Mode, behavior returns to what’s described in the bug report.

As for extensions, by default I have “Dark Reader”, “ImportExportTools NG” and “Provider for Google Calendar” all enabled, whilst “FolderFlags”, “Manually sort folders” and “Unified Folders Debugging” are all forcibly disabled (as they’re not compatible with Tbird v136.0.1).
The problem persists even when all extensions are disabled (but without activating Troubleshoot Mode).

Flags: needinfo?(joemcken64)

Something else which can be disabled in TRoubleshoot mode is hardware acceleration.
Please Test:

  • Settings > General
  • Scroll to bottom
  • uncheck this option: Use hardware acceleration when available'
  • Exit and restart Thunderbird.

Please report on results.

If no effect then please TEST:

whilst “FolderFlags”, “Manually sort folders” and “Unified Folders Debugging” are all forcibly disabled (as they’re not compatible with Tbird v136.0.1).
Maybe disabled addons still have some setting effecting code. There's only one way to find out :)
If they still exist in the list of addon extensions they please uninstall them and then restart Thunderbird.
Please report on results.

Flags: needinfo?(joemcken64)

(In reply to Anje from comment #4)

Something else which can be disabled in TRoubleshoot mode is hardware acceleration.
Please Test:

  • Settings > General
  • Scroll to bottom
  • uncheck this option: Use hardware acceleration when available'
  • Exit and restart Thunderbird.

Just tested this. Disabling hardware acceleration has no effect on the issue.

Maybe disabled addons still have some setting effecting code. There's only one way to find out :)
If they still exist in the list of addon extensions they please uninstall them and then restart Thunderbird.

I have uninstalled the three disabled add-ons and restarted Thunderbird. No change, issue still present.

Flags: needinfo?(joemcken64)

Good info. Then the cause is one of the addons which you have not yet disabled or uninstalled.

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

Good info. Then the cause is one of the addons which you have not yet disabled or uninstalled.

I just uninstalled all remaining add-ons (Dark Reader, ImportExportTools NG & Provider for Google Calendar). The issue persists.

(I’m reinstalling them now.)

I just uninstalled all remaining add-ons (Dark Reader, ImportExportTools NG & Provider for Google Calendar). The issue persists.

Perhaps an addition Help > Troubleshoot Mode is needed?

Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Resolution: --- → INVALID

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

I just uninstalled all remaining add-ons (Dark Reader, ImportExportTools NG & Provider for Google Calendar). The issue persists.

Perhaps an addition Help > Troubleshoot Mode is needed?

Just tried Troubleshoot Mode. Issue persists there, too. Enabled unified folders, and the new message button doesn’t work when a category header (“Inbox”, “Drafts”, etc.) is selected, but does work when individual accounts within those categories are selected.

Closing the bug as “resolved invalid” seems premature, as it is very much still occurring for me.

Apparently the default identity couldn't be determined for some reason, then this the expected behavior (see source code). Can you check if an account is set as default (shown with a yellow star) in Account Settings?

(In reply to Hartmut Welpmann [:welpy-cw] from comment #10)

Apparently the default identity couldn't be determined for some reason, then this the expected behavior (see source code). Can you check if an account is set as default (shown with a yellow star) in Account Settings?

Thanks for the info. I checked Account Settings, and indeed no account was set as default (none had a gold star). I clicked “Set as Default” for my primary personal account (a gold star appeared), and now indeed the “Write” button & Ctrl+N shortcut work when a unified folder header is selected, defaulting to that default account. Given that this now works and that I don’t see any “remove default” button, I take it that Thunderbird isn’t supposed to not have a set default account?

Yeah not supposed to happen.

Summary: Can’t create new email when unified folder is enabled → Can’t create new email when unified folder is enabled (if no default account was set)

Odd. Wonder how it happened then. Ah well, good that it’s resolved.

See Also: → 1976624
Severity: -- → S3
Status: RESOLVED → REOPENED
status-thunderbird_esr128: --- → unaffected
status-thunderbird_esr140: --- → affected
tracking-thunderbird_esr140: --- → ?
Ever confirmed: true
Keywords: regression
Regressed by: 1919144
Resolution: INVALID → ---
Summary: Can’t create new email when unified folder is enabled (if no default account was set) → Can’t create new email/message when unified folder is enabled (if no default account was set)
tracking-thunderbird_esr140: ? → +
Priority: -- → P2
Duplicate of this bug: 1976624

If bug 1919144 is the accurate regressor, then this started in Thunderbird 133.

Version: Thunderbird 136 → Thunderbird 133
Assignee: nobody → h.w.forms
Status: REOPENED → ASSIGNED
Attachment #9500213 - Attachment description: Bug 1956258 - Ensure default account is set when composing a message. r=#thunderbird-reviewers → Bug 1956258 - Have default account getter auto-set a viable account. r=BenC,darktrojan
Duplicate of this bug: 1977187
Keywords: checkin-needed-tb
Target Milestone: --- → 142 Branch

Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/c4e7236f8b0e
Have default account getter auto-set a viable account. r=BenC,darktrojan

Status: ASSIGNED → RESOLVED
Closed: 1 year ago → 10 months ago
Keywords: checkin-needed-tb
Resolution: --- → FIXED
Blocks: tb140found

This will be included in next Monday's merge of central->beta. Can we get an uplift request for 140esr?

Comment on attachment 9500213 [details]
Bug 1956258 - Have default account getter auto-set a viable account. r=BenC,darktrojan

Uplift Approval Request

  • Please state case for uplift consideration and ensure bug severity is set: Relatively recent regression not present in the previous ESR.
  • User impact if declined: For profiles without an explicitly set default account, when trying to send a message from unified or local folders simply nothing happens.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Daily?: Yes
  • Has the fix been verified in Beta?: No
  • Needs manual test from QA?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): There should be no particular risk at all. The code only affects the case that no default account is set, which shouldn't happen in the first place (but does under certain circumstances). Not uplifting this is definitely riskier, since after regressing bug 1919144 not having a default account set has more severe implications than before.
  • Does the fix cause any migrations to be skipped?: No
  • String changes made/needed: None.
Attachment #9500213 - Flags: approval-comm-esr128? → approval-comm-esr140?
See Also: → 1977609
See Also: 1977609 →
See Also: → 1977609

(In reply to Hartmut Welpmann [:welpy-cw] from comment #21)

  • Why is the change risky/not risky? (and alternatives if risky):

Hartmut, please can you fill this out? I know it feels like busy work but it's important to weigh out the regression potential of this fix. ie. where could things go wrong if it introduces a regression? Thanks.

(In reply to Corey Bryant from comment #22)

(In reply to Hartmut Welpmann [:welpy-cw] from comment #21)

  • Why is the change risky/not risky? (and alternatives if risky):

Hartmut, please can you fill this out? I know it feels like busy work but it's important to weigh out the regression potential of this fix. ie. where could things go wrong if it introduces a regression? Thanks.

Yes, of course. See updated comment 21.

Flags: needinfo?(corey)

Comment on attachment 9500213 [details]
Bug 1956258 - Have default account getter auto-set a viable account. r=BenC,darktrojan

[Triage Comment]
Approved for esr140

Flags: needinfo?(corey)
Attachment #9500213 - Flags: approval-comm-esr140? → approval-comm-esr140+
See Also: → 1980859
Duplicate of this bug: 1980859
Duplicate of this bug: 1981831
See Also: 1980859 →
Regressions: 1991298
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: