Closed Bug 1807063 Opened 2 years ago Closed 11 months ago

State of collapsed/expanded thread is not maintained

Categories

(Thunderbird :: Folder and Message Lists, defect, P2)

Thunderbird 115

Tracking

(thunderbird_esr115+ fixed, thunderbird120? fixed)

RESOLVED FIXED
121 Branch
Tracking Status
thunderbird_esr115 + fixed
thunderbird120 ? fixed

People

(Reporter: aleca, Assigned: welpy-cw)

References

Details

(Keywords: regression)

Attachments

(1 file)

The state of collapsed threads is not maintained upon restart if single threads are opened or closed.
If all threads are opened or closed with the specific command, the state is remembered.
The issue happens only if threads are opened manually by clicking on the chevron.

This started happening recently, but I'm not sure about the correct regression window.

There seems to be some confusion what the desired and established behaviour should be, here and also in bug 1849960. Both show up with this search: https://mzl.la/3Lt7gSz.

In 102 the bahaviour is this:

For a folder, threads can be collapsed or expanded (\ or *). This is persisted when the folder is left and revisited and also across restart.

Collapsed/expanded states for individual threads were never persisted. However, if a message was selected in a manually expanded thread in a generally collapsed folder, then that one thread was expanded again on leaving the folder and returning to be able to show the selection again. This does no longer work in Supernova, amongst other things reported in bug 1851320.

Summary: State of collapsed thread is not maintained → State of collapsed/expanded thread is not maintained
Duplicate of this bug: 1849960
Duplicate of this bug: 1852693

Restore the collapsed or expanded state of threaded or grouped by sort views when selecting
a folder. Threads or groups containing previously selected messages are opened in any case if
possible.

Assignee: nobody → h.w.forms
Status: NEW → ASSIGNED

restoreSelection() is called twice when a folder is entered:

restoreSelection chrome://messenger/content/about3Pane.js:4955
_onSelect chrome://messenger/content/about3Pane.js:2540

and

restoreSelection chrome://messenger/content/about3Pane.js:4955
onMessagesLoaded chrome://messenger/content/mailCommon.js:963

Can you please clarify why restoreSelection() is called twice.

The issue we mentioned in comment #5 is really the root of the problem why Hartmut's patch only works sometimes. Adding some debugging to restoreSelection() shows that this function is called twice or three times on entering a folder. That doesn't appear to be correct. Blocking those excessive calls with a 100 ms gate makes the patch work. Quite a hack, but we believe the overall architecture should be straightened out here to just restore the selection once together with the thread state (bug 1851320).
https://github.com/Betterbird/thunderbird-patches/blob/main/115/bugs/1807063-restore-thread-state.patch

We toned down the hack a bit, now the calls are bundled and run in a setTimeout().

Attachment #9356746 - Attachment description: Bug 1807063 - Restore thread state when selecting folder. r=#thunderbird-front-end-reviewers → WIP: Bug 1807063 - Restore thread state when selecting folder. r=#thunderbird-front-end-reviewers
Attachment #9356746 - Attachment description: WIP: Bug 1807063 - Restore thread state when selecting folder. r=#thunderbird-front-end-reviewers → WIP: Bug 1807063 - Restore thread state when selecting folder. r=darktrojan

Thanks for attributing our investigation re. "grouped by sort" views. Please consider also taking the following patch. Currently "collapse all threads" and "collapse single thread" gives different results when restoring the selection after leaving and returning to a folder. This is also due to the behaviour of getting DB keys for dummy rows, which returns the key of the first group member.
https://github.com/Betterbird/thunderbird-patches/blob/main/115/bugs/1807063-fix-saving-selection.patch

Attachment #9356746 - Attachment description: WIP: Bug 1807063 - Restore thread state when selecting folder. r=darktrojan → Bug 1807063 - Restore thread state when selecting folder. r=darktrojan
Duplicate of this bug: 1851320
See Also: → 1411905
Duplicate of this bug: 1859721
Duplicate of this bug: 1858442
Attachment #9356746 - Attachment description: Bug 1807063 - Restore thread state when selecting folder. r=darktrojan → WIP: Bug 1807063 - Restore thread state when selecting folder. r=darktrojan

Not sure if related, but in Supernova the following annoying behaviour started:

  1. Search in a folder using the Quick Filter
  2. Reset the filter
  3. All threads are expanded, even if they were all/most collapsed before the search.

(In reply to Nicola Soranzo from comment #12)

Not sure if related, but in Supernova the following annoying behaviour started:

  1. Search in a folder using the Quick Filter
  2. Reset the filter
  3. All threads are expanded, even if they were all/most collapsed before the search.

Yes, I am aware of that. This will be fixed as well.

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

Yes, I am aware of that. This will be fixed as well.

That's great, thank you for confirming!

Attachment #9356746 - Attachment description: WIP: Bug 1807063 - Restore thread state when selecting folder. r=darktrojan → Bug 1807063 - Restore thread state when selecting folder. r=darktrojan

Another reason why new interface is confusing: when all thread are expanded new ones appear collapsed.

Duplicate of this bug: 1848479
Duplicate of this bug: 1687655
Severity: -- → S3
Priority: -- → P2
Version: unspecified → Thunderbird 115
Duplicate of this bug: 1860608
Target Milestone: --- → 121 Branch

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/a1f852ae5b9a
Restore thread state when selecting folder. r=darktrojan

Status: ASSIGNED → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
See Also: → 1854865
Duplicate of this bug: 325252
Attachment #9356746 - Flags: approval-comm-beta?

Comment on attachment 9356746 [details]
Bug 1807063 - Restore thread state when selecting folder. r=darktrojan

[Triage Comment]
Approved for beta

Attachment #9356746 - Flags: approval-comm-beta? → approval-comm-beta+

good for 115?

Flags: needinfo?(h.w.forms)

Yes, I think this fixes a lot of things that have been reported recently. By disabling selection persistence in multi-folder views such as unified folders, this also mitigates the problem of selecting the wrong messages as reported in bug 1857766. This functionality should be implemented in another patch soon.

Flags: needinfo?(h.w.forms)
Attachment #9356746 - Flags: approval-comm-esr115?

Comment on attachment 9356746 [details]
Bug 1807063 - Restore thread state when selecting folder. r=darktrojan

[Triage Comment]
Approved for esr115

Attachment #9356746 - Flags: approval-comm-esr115? → approval-comm-esr115+
Regressions: 1864352
See Also: → 1857766
Regressions: 1864987
Regressions: 1866553
Duplicate of this bug: 1863311
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: