1798133 - selectFolder fails If activeModes is not only "all"

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[itagagaki]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36 Edg/106.0.1370.52

Steps to reproduce:

Assumption:
gFolderTreeView.activeModes is [all,favorite]
folderA and folderB are subfolders in favorite view.
folderC is a subfolder in all view but not in favorite view.
All subfolders collapsed into parent folders and are not visible.

Steps to reproduce:
resultA = gFolderTreeView.selectFolder(A);
resultB = gFolderTreeView.selectFolder(B);
resultC1 = gFolderTreeView.selectFolder(C);
resultC2 = gFolderTreeView.selectFolder(C, true);

Actual results:

resultA and resultB are true.
resultC1 and resultC2 are false.
gFolderTreeView.selectFolder(C, true); will leave the folder pane with only favorite view (the all view will disappear).

Expected results:

All four results return true and the specified folder is selected.
The state of the folder pane (activeModes) does not change.

Comment 1

[itagagaki]

It might be related with bug 350839
If C is visible, it will not reproduce.

Comment 2

[Magnus Melin [:mkmelin]]

Would you like to submit a patch?
Is it causing any problem that can be triggered through the UI?

Comment 3

[itagagaki]

This issue occurs when the add-on "Manually sort folders" starts and selects a folder that has been set as the startup folder by user. I found this issue after investigating rare reports of it not working.
It may not be possible to observe this issue with pure Thunderbird without any add-ons.

In order for me to submit a patch, I first need to get my Thunderbird build and test environment in place. Next I need to understand the mechanics
and intent of the current code and find out where the mistakes are. That will take a while. So I think the right person should be in place.

Comment 4

[Magnus Melin [:mkmelin]]

Don't sell yourself short ;) See https://developer.thunderbird.net/thunderbird-development/getting-started

Comment 5

[itagagaki]

I have found that this issue can occur with pure TB UI, not just against add-ons.

Steps to reproduce:

1. Create a new empty profile
2. Add one account of some kind
3. Add folders A and B under Local Folders
4. Check folder A as Favorite Folder
5. Set the Menu Bar to display
6. [View]->[Folders] Make sure only All is checked
7. [View]->[Folders] Check Favorite
8. Close (collapse) all folders in "Favorite Folders" view and "All Folders" view
9. [Go]->[Folder]->[Local Folders]->[B]

Actual results:

"All Folders" view disappears. Only "Favorite Folders" view remains.
Folder B is not there, so of course it is not selected.

Expected results:

Folder B under Local Folders in "All Folders" view should be selected.

I am also trying to analyze the code but have not been able to elucidate it.
So If you have a suitable person, please assign him or her.

Comment 6

[itagagaki]

I figured out what was wrong. And I fixed it.
How do I create and submit a patch, I am new to contributing to Mozilla.

Comment 7

[Magnus Melin [:mkmelin]]

Great! See https://developer.thunderbird.net/thunderbird-development/fixing-a-bug#configuring-mercurial

Comment 8

[itagagaki]

I've read the docs but I'm stuck, when I run moz-phab I get the following error, but I don't know how to fix it.

Unable to submit commits:

Found patches applied with mq, unable to continue

developer.thunderbird.net recommends using Mercurial Queues and says to use moz-phab to submit patches. But I faced the above error.

wiki.mozilla.org says

Does moz-phab work with mq (Mercurial Queues)
No. mq was deprecated 5+ years ago; please use evolve instead.

I am confused. I don't know where to ask the question so I wrote it here.
I would appreciate it if you could give me explanation.

Comment 9

[Magnus Melin [:mkmelin]]

Yeah we need to update that. Don't use mq, and do a normal commit. If you have the patch, "hg qfinish" and don't look back.

Comment 10

[itagagaki]

Attachment: Bug 1798133 - Fix gFolderTreeView.selectFolder to be as expected.

Comment 11

[itagagaki]

Attachment: Bug 1798133 - Fix gFolderTreeView.selectFolder to be as expected. r=mkmelin

Comment 12

[itagagaki]

Attachment: SSH public key

Comment 13

[itagagaki]

I have read, and agree to abide by, the Commit Access Requirements.

Comment 14

[itagagaki]

Sorry, I don't have the permission of Level 3 Commit Access. What can I do?

Comment 15

[Magnus Melin [:mkmelin]]

Hey, you don't need to do anything. Someone will check the patch in for the next merge, that's how we use the checkin-needed-tb keyword.
Account rights would need to go to a bug of it's own, see https://www.mozilla.org/en-US/about/governance/policies/commit/ for the procedures (level 1 to begin start with)

Comment 16

[itagagaki]

I see. Okay.
I got an email from Phabricator saying "You can now land this revision," so I thought I should get the permission and do merging.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/fbd962974310
Fix gFolderTreeView.selectFolder to be as expected. r=mkmelin

Comment 18

[Alessandro Castellani [:aleca]]

Thank you so much Itagagaki for contributing and fixing the issue.

The steps reported in comment 5 are perfect for a test case.

Create a new empty profile
Add one account of some kind
Add folders A and B under Local Folders
Check folder A as Favorite Folder
Set the Menu Bar to display
[View]->[Folders] Make sure only All is checked
[View]->[Folders] Check Favorite
Close (collapse) all folders in "Favorite Folders" view and "All Folders" view
[Go]->[Folder]->[Local Folders]->[B]

We need to have a test covering this scenario, especially since we're rebuilding the entire folder pane in ash and we need to be sure we're not re-introducing old regressions.

Magnus, would you be able to take care of this?

Comment 19

[Magnus Melin [:mkmelin]]

Note to self: can probably build on mail/test/browser/folder-pane/browser_displayMessageWithFolderModes.js