Cannot change sort order of accounts (implemented fix: DnD in account manager, pref: mail.accountmanager.accounts)
Categories
(MailNews Core :: Account Manager, enhancement)
Tracking
(thunderbird_esr78- wontfix, thunderbird84 wontfix)
People
(Reporter: floeff, Assigned: freaktechnik)
References
()
Details
(Keywords: ux-control, Whiteboard: [gs][Alternative UI from addon, see URL; see comment 42, 52, 62])
User Story
The fix implemented here: - In account manager, drag and drop accounts into the right order. Applies immediately without restarting TB. - controlled via string pref: `mail.accountmanager.accounts` mail.accountmanager.accounts => "account1,account3,account2" Some hints to correlate the account IDs (account1, account2, etc.) with your actual accounts: `≡ > Help > More Troubleshooting Information...`: *Mail and News Accounts*
Attachments
(3 files, 15 obsolete files)
Updated•21 years ago
|
Comment 1•21 years ago
|
||
Comment 2•18 years ago
|
||
Updated•18 years ago
|
Comment 3•18 years ago
|
||
Updated•18 years ago
|
Comment 6•17 years ago
|
||
Comment 7•17 years ago
|
||
Comment 9•17 years ago
|
||
Updated•17 years ago
|
Updated•16 years ago
|
Updated•16 years ago
|
Comment 14•15 years ago
|
||
Comment 15•15 years ago
|
||
Comment 16•15 years ago
|
||
Comment 17•14 years ago
|
||
Comment 18•14 years ago
|
||
Comment 19•14 years ago
|
||
Comment 20•14 years ago
|
||
Comment 21•14 years ago
|
||
Comment 22•14 years ago
|
||
Comment 23•14 years ago
|
||
Comment 24•14 years ago
|
||
Comment 26•14 years ago
|
||
Updated•14 years ago
|
Comment 27•14 years ago
|
||
Comment 29•13 years ago
|
||
Comment 30•13 years ago
|
||
Comment 31•13 years ago
|
||
Comment 32•12 years ago
|
||
Comment 34•12 years ago
|
||
Comment 35•12 years ago
|
||
Comment 36•12 years ago
|
||
Comment 37•12 years ago
|
||
Comment 38•12 years ago
|
||
Comment 39•12 years ago
|
||
Comment 40•12 years ago
|
||
Comment 41•12 years ago
|
||
Comment 42•12 years ago
|
||
Comment 43•12 years ago
|
||
Comment 44•12 years ago
|
||
Comment 45•12 years ago
|
||
Comment 46•12 years ago
|
||
Comment 47•12 years ago
|
||
Comment 48•12 years ago
|
||
Comment 49•12 years ago
|
||
Comment 50•12 years ago
|
||
Comment 51•12 years ago
|
||
Comment 52•12 years ago
|
||
Comment 53•12 years ago
|
||
Comment 54•12 years ago
|
||
Comment 55•12 years ago
|
||
Comment 56•12 years ago
|
||
Comment 57•12 years ago
|
||
Updated•12 years ago
|
Comment 58•12 years ago
|
||
Comment 59•12 years ago
|
||
Comment 60•11 years ago
|
||
Updated•11 years ago
|
Comment 61•11 years ago
|
||
Comment 62•11 years ago
|
||
Comment 64•8 years ago
|
||
Comment 66•8 years ago
|
||
Comment 67•8 years ago
|
||
Comment 72•7 years ago
|
||
Comment 73•7 years ago
|
||
Comment 74•7 years ago
|
||
Comment 75•7 years ago
|
||
Comment 76•7 years ago
|
||
Comment 77•7 years ago
|
||
Comment 78•7 years ago
|
||
Comment 79•7 years ago
|
||
Comment 80•7 years ago
|
||
Comment 81•7 years ago
|
||
Comment 82•7 years ago
|
||
Comment 83•7 years ago
|
||
Comment 84•7 years ago
|
||
Comment 85•7 years ago
|
||
Comment 86•7 years ago
|
||
Comment 87•7 years ago
|
||
Comment 88•7 years ago
|
||
Comment 89•7 years ago
|
||
Comment 90•7 years ago
|
||
Comment 91•7 years ago
|
||
Comment 92•7 years ago
|
||
Comment 93•7 years ago
|
||
Comment 94•7 years ago
|
||
Comment 95•7 years ago
|
||
Comment 96•7 years ago
|
||
Comment 97•7 years ago
|
||
Updated•7 years ago
|
Comment 98•7 years ago
|
||
Comment 99•7 years ago
|
||
Comment 100•7 years ago
|
||
Updated•5 years ago
|
Comment 102•5 years ago
|
||
can we please have something added to be able to change the order of the accounts.
i shouldnt have to rely on addons to do such a simple thing
https://addons.thunderbird.net/en-US/thunderbird/addon/manually-sort-folders/
this addon is now out of date for version 68 and up
Comment hidden (metoo) |
Comment 104•5 years ago
|
||
All this back and forth of ideas and yet this simple task has not been implemented since 16 (!) years.... why not exactly?
Couldn't be a simple approach of [- +] or [˄ ˅] icons beside the account panel in AM possible, yet a shortcut like ALT+"+" and ATL+"-", icons accessible with tabulator?
Please, can we have this in 2020?
Comment 105•5 years ago
|
||
Welcome Markus. To answer the "Why not exactly": Because you have not implemented this "simple task" by providing a patch. Furthermore, age of a ticket is entirely irrelevant because anyone can propose any random idea. That does not mean that someone decides to work on it though.
It is up to you to provide patches if you want to see something fixed. See https://www.thunderbird.net/en-US/get-involved/#development
Comment 106•4 years ago
|
||
After all discussion, I think we should as a first step add dnd in the account manager. Maybe with keyboard shortcuts like comment 41.
Not too keen on any further dialogs, and also the whole Account Actions button, which is disconnected from the account...
We'll want to extract backend code from the patch in bug 1359410.
Comment 107•4 years ago
|
||
In the account manager, doing "option + up" and "option + down" will change the order of the accounts and that will be reflected in the Message Pane WIndow. If the user wants default order, "mail.accountmanager.accounts.ordered" can be set to false. Right now, we don't have any preferences but we can have a checkbox in the Preferences for Default Thunderbird Accounts order or Manual Accounts order which will trigger "mail.accountmanager.accounts.ordered".
Updated•4 years ago
|
Updated•4 years ago
|
Comment 108•4 years ago
|
||
Comment 109•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #108)
I think the idea would be to not have this pref but instead do a one time
setup of the pref for how the account are ordered.
(Also need need to remember to update that pref when accounts are
added/removed).
Should we use "mail.accountmanager.accounts" pref for this? It already contains the list of account keys in the order of their creation date/time.
So initially, we have 1 Email account with "account1" and the local folder account with "account2". If we add another account which will be "account3". We are sorting in a way that the local folder with "account2" will come last always, so the order will be in the view: "account1, account3, account2". And the pref "mail.accountmanager.accounts" will be "account1, account2, account3". So how do you want to order it by default and when account is added and removed?
And we also need to indicate users how they can change the order. What should we do for that?
Comment 110•4 years ago
|
||
Honestly, allowing that even by changing some entry in advanced prefs and putting account numbers like 1,5,2,4,3,6 instead of 1,2,3,4,5,6 would be good. There was an add-on for that, mentioned in this thread (Manually sort folders) and it worked great. If you'd like to check it out but won't be able to find it, I can upload it somewhere and share a link. Implementing something like that into the app would be the most elegant solution but just making it possible to change the order in any way is infinitely better than having no option whatsoever to change that.
Comment 111•4 years ago
|
||
(In reply to pufcio from comment #110)
Honestly, allowing that even by changing some entry in advanced prefs and putting account numbers like 1,5,2,4,3,6 instead of 1,2,3,4,5,6 would be good. There was an add-on for that, mentioned in this thread (Manually sort folders) and it worked great. If you'd like to check it out but won't be able to find it, I can upload it somewhere and share a link. Implementing something like that into the app would be the most elegant solution but just making it possible to change the order in any way is infinitely better than having no option whatsoever to change that.
I agree with pufcio.
Comment 112•4 years ago
|
||
I too agree with pufcio.
If I understand right, he first wants to have bug 1359410 fixed promptly. Don't wait until we have a GUI according this bug.
Comment 113•4 years ago
|
||
Comment 114•4 years ago
|
||
Comment 115•4 years ago
|
||
Comment 116•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #115)
what is this for?
Maybe it should only show drop allowed where it can, i.e. not the account
manager sections (server settings, copies & folders etc.)
By default, data/elements cannot be dropped in other elements. To allow a drop, we must prevent the default handling of the element.
Comment 117•4 years ago
|
||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 118•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #115)
I now get Local Folders on top. I think you need to do a one time migration
of the current "normal order".
Really guys, what are you trying to achieve here? The order of accounts must not change after the patch, only there must appear a possibility to reorder them manually. But users that don't touch that, should get the automatic ordering. Also remember new accounts get appended to the end of the list, but it will be wrong if they always appear on the bottom of the UI (for some account types it will be wrong).
So why are you undoing bug 749200 (automatic ordering by account type)? Where is the UI and UX discussion of this?
Comment 119•4 years ago
|
||
That's why I requested that the current order is migrated into the normal ordering - that way there is not really a change in UI/UX on that part. Except that if you do decide to rearrange accounts you get to use an ordering of your choice.
Re adding accounts, I think new accounts should not go below Local Folders, but other than that there's little sense in putting news accounts below other accounts. If I add it second, why wouldn't I want it second? (And in the new world, I'd just move it up/down anyway.)
Comment 120•4 years ago
|
||
protz mentions:
For sorting accounts: Thunderbird developers have committed to allowing sorting accounts (not folders) directly within Thunderbird, without the need for an addon. This will reuse some code that I (and others) wrote, which allows arbitrary reordering of accounts, meaning that this will be fixed automatically when the next version of Thunderbird comes out.
Manually Sort Folders had a good solution for reordering accounts in the Folder Pane.
Can I ask...are you making use of this code so kindly proffered?
Comment 121•4 years ago
|
||
Comment 122•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #119)
Re adding accounts, I think new accounts should not go below Local Folders, but other than that there's little sense in putting news accounts below other accounts.
So with the patch, everything will go below Local Folders, as Local Folders is created first (or second).
If I add it second, why wouldn't I want it second? (And in the new world, I'd just move it up/down anyway.)
Because in bug 749200 it was decided we do not want such mess? Yes, it will now be possible to manually reorder the accounts.
Comment 123•4 years ago
|
||
Comment 125•4 years ago
|
||
Comment 126•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #125)
why not the im accounts? Even if not shown in the 3 pane, one should be able
to reorder them in the account manager and have that stick.Oh, I see we also have an messenger.accounts pref for IM, and that can
already be reordered in the im account win.
We should probably unify this here as well so that we migrate that away to
using the main list.
Keys in "messenger.accounts" and keys from "MailServices.accounts.accounts" are different. "messenger.accounts" value is "account1,account2"(in increasing order of all the chat accounts) in this order whereas in "MailServices.accounts.accounts", im accounts keys can be "account3", "account4"(in the increasing order of all the accounts). So this is not possible.
Comment 127•4 years ago
|
||
Comment 128•4 years ago
|
||
Comment 129•4 years ago
|
||
Actually, since local folders isn't listed in the account manager it can't be anywhere else except last. We should just always add new accounts before it, never after.
Comment 130•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #129)
Actually, since local folders isn't listed in the account manager it can't be anywhere else except last. We should just always add new accounts before it, never after.
From an UX perspective, not being able to move local folders freely might look like an unwarranted limitation (ux-implementation-level).
Comment 131•4 years ago
|
||
(In reply to Thomas D. (:thomas8) from comment #130)
(In reply to Magnus Melin [:mkmelin] from comment #129)
Actually, since local folders isn't listed in the account manager it can't be anywhere else except last. We should just always add new accounts before it, never after.
From an UX perspective, not being able to move local folders freely might look like an unwarranted limitation (ux-implementation-level).
This can be handled with a simple dialog box popup stating that Local Folders are always at the end due to a limitation forced by the structure of the application or program. The dialog box options could be as simple as {check box}Do Not show Again and [Next}
Comment 132•4 years ago
|
||
If we do dnd of account in the folder pane later we could allow it to be moved. But atm since it's not in the account manager, we should just keep it where it is for now. There is also the complication that it's (I think, unfortunately still) possible to set up pop accounts that are using Local Folders and not their own account node (the global inbox mode).
Comment 133•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #129)
Actually, since local folders isn't listed in the account manager it can't be anywhere else except last. We should just always add new accounts before it, never after.
"Local Folders" is listed in the the account manager for me. Can you explian this a bit more?
Comment 134•4 years ago
|
||
still don't understand. When Mozila owned Thunderbird I could move accouns to any order I wanted. Now I can't.
Comment 135•4 years ago
|
||
FYI, the ability to move Local Folders on top was offered by my addon, until some Thunderbird changes made it impossible, at which points users started complaining pretty loudly. So I suspect it's a common feature request to be able to move all accounts freely (which was the intention behind my previous patch).
Comment 136•4 years ago
|
||
(In reply to Khushil Mistry [:khushil324] from comment #133)
"Local Folders" is listed in the the account manager for me. Can you explian this a bit more?
Sorry, ignore me, I forgot they are :)
I still think that if Local Folders are last (== no customize happened), new accounts should be inserted before them in the list.
Comment 137•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #128)
I think when adding new accounts, if Local Folders is the last account, the
new account should be added before Local Folders.
If local folders is not last, then the order has been customized and we'd
just add it last.
Currently, we put RSS and News Feed after local folders. So what to do in that case? I feel that we should not have any special cases for local folders and treat them like the normal account.(In reply to Magnus Melin [:mkmelin] from comment #128)
The UX of trying to drag something to first position is a bit weird (can't
be done). I think usually if you drag something and drop it on the first
itme, the expectation is the dropped item moves to top.There is also no drop indicator. Can we add one?
I will try for a drop-indicator but it seems a little difficult. Let me check again.
getElementById fore these please
It's showing an error when we try to use getElementById: JavaScript error: chrome://messenger/content/AccountManager.js, line 1815: TypeError: mainTree.getElementById is not a function
Comment 138•4 years ago
|
||
(In reply to Khushil Mistry [:khushil324] from comment #137)
Currently, we put RSS and News Feed after local folders. So what to do in that case? I feel that we should not have any special cases for local folders and treat them like the normal account.
I'd just keep Local Folder last, until a user modification moves it elsewhere.
I think what we want to avoid here is that Local Folders ends up as the first account for all new profiles. You only have local folders initially, then you add more, which would go below, which is not nice.
Aleca, wdyt?
Comment 139•4 years ago
|
||
I agree with having Local Folder always at last position unless a user changes it.
I think we can safely assume that, as a default, users are more interest in their remote accounts than the automatically created local folder.
Having the ability to reorder it is good, but by default it should always be pushed at the last position.
Comment 140•4 years ago
|
||
Regarding the drop indicator, we should use the tab-drag-indicator.svg
we currently use for tab and copied from Firefox.
You can easily rotate it with CSS. https://searchfox.org/comm-central/search?q=tab-drag-indicator.svg&path=
I don't think it's possible to use :after/before
pseudo elements in the richlist XUL element, which is a shame as that would have been very easy to handle.
Comment 141•4 years ago
|
||
What's about positioning a new created account always directly above Local Folders regardless it's position?
If the user wants the new created account at another position, he can move it manually.
(In reply to Alessandro Castellani (:aleca) from comment #140)
I don't think it's possible to use
:after/before
pseudo elements in the richlist XUL element, which is a shame as that would have been very easy to handle.
In Firefox at the search engine settings, the is the possibility, to move an element to the top position. Maybe this code can be used to move the folders in TB.
Also with bookmarks in FF I see this functionality.
Comment 142•4 years ago
|
||
Idea: People maybe used to the import function in address book.
The import address book text file uses a three column table structure with Move up and Move down buttons.
If far left column (checkbox) could be used as a means of setting of default account. Only one checkbox can be selected.
If inner left column was a numbered position in list, then right column could be list of accounts names.
Move up/Move down buttons move selected mail account (third/right column) to match position number.
Maybe additional buttons 'Move to Top' & 'Move to bottom' to save some clicking.
I'm not saying life is that simple, but............. :)
Comment 143•4 years ago
|
||
There is a problem with drop indicator, we are not able to apply styling to the tree element. So I have skipped that part right now.
Comment 144•4 years ago
|
||
Comment 145•4 years ago
|
||
Great, thanks for this. Let me try!
Comment 146•4 years ago
|
||
I would just like to add support for protz' code / the ability to change the order of accounts to be implemented (particularly moving Local folders to the top of the accounts list) in whatever is the simplest fashion - add the ability for users to manually change and leave the rest of the ordering as is if that can be done. I can see there is alot of debate about various options, but we just want to see the ability to sort implemented and further tweaks to be applied later if needed.
There is a significant (200k+) userbase of protz's manually sort folder add-on, which it no longer functions for users running a current or near-current version of TB. This is significantly causing angst and noise in a large portion of the TB community. Thanks
Updated•4 years ago
|
Comment 147•4 years ago
|
||
Comment 148•4 years ago
|
||
Comment 149•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #148)
I don't understand the purpose of this pref.
If local folders is last, nothing to do. If that account is not last, it was
moved and order should be honoured. The migration should take care that the
list of accounts is what is should be.
When we add a new account, it gets appended in MailServices.accounts.accounts
list. So now, "local folders" will not be last on the list. allAccountsSorted function
is the util function that returns the required account order. So this pref is set up in the account setting window when the user changes the order and allAccountsSorted util function
will use this pref to return the required account order despite "local folders" is not last in the MailServices.accounts.accounts
list.
We can do another thing: when we append the account in the MailServices.accounts.accounts
, check at that time only. But I am not sure how much complexity it will add and how much c++ work will it require.
Any thoughts?
Comment 150•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #148)
I believe the incominserver.sortOrder attribute can (and should be) be
removed
https://searchfox.org/comm-central/rev/
25df033ac98c8cb346a8e0c338d1e7647ca23bfb/mailnews/base/public/
nsIMsgIncomingServer.idl#537
Let's do it in the follow-up bug. It will add more complexity here.
Comment 151•4 years ago
|
||
We can do something here related to my second suggestion: https://searchfox.org/comm-central/source/mail/components/accountcreation/content/createInBackend.js#21
Comment 152•4 years ago
|
||
(In reply to Khushil Mistry [:khushil324] from comment #149)
When we add a new account, it gets appended in
MailServices.accounts.accounts
list. So now, "local folders" will not be last on the list.allAccountsSorted function
is the util function that returns the required account order. So this pref is set up in the account setting window when the user changes the order andallAccountsSorted util function
will use this pref to return the required account order despite "local folders" is not last in theMailServices.accounts.accounts
list.
Wouldn't the suggestion from comment 141 solve the problem?
Comment 153•4 years ago
|
||
I have updated the patch and removed the usage of extra pref.
Updated•4 years ago
|
Comment 154•4 years ago
|
||
Comment 155•4 years ago
|
||
Looks to me such checks should be around here: https://searchfox.org/comm-central/rev/25df033ac98c8cb346a8e0c338d1e7647ca23bfb/mailnews/base/src/nsMsgAccountManager.cpp#1525-1545
Something like
nsCString localFoldersAccountKey;
nsCOMPtr<nsIMsgIncomingServer> localFoldersServer;
rv = GetLocalFoldersServer(getter_AddRefs(localFoldersServer));
if (NS_SUCCEEDED(rv)) {
for (auto account : m_accounts) {
nsCOMPtr<nsIMsgIncomingServer> server;
rv = account->GetIncomingServer(getter_AddRefs(server));
if (NS_SUCCEEDED(rv) && server == localFoldersServer) {
account->GetKey(localFoldersAccountKey);
break;
}
}
}
Then, if local is the only account, or last, insert the new account before it. Otherwise append the new account last.
Updated•4 years ago
|
Comment 156•4 years ago
|
||
Comment 157•4 years ago
|
||
Comment 158•4 years ago
|
||
Comment 159•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #157)
I'd think these require some time to make sure the event was actually acted
upon, like
await new Promise(resolve => setTimeout(resolve));Same for VK_UP above
Using mc.sleep(0)
as we are using it with EventUtils.synthesizeKey
at various places.
Comment 160•4 years ago
|
||
Using mc.sleep(0) as we are using it with EventUtils.synthesizeKey at various places.
Quick fly by suggestion.
I did implement some mc.sleep(0)
in the past but they ended up biting me after a while.
It's better to not set an arbitrary timeout since we open up to the possibility of intermittent failures if something runs slightly slower, and that happens more often than none especially when all the tests from the same folder are running.
I suggest to use waitForEvent or waitForCondition, if applicable to this situation, so we don't have to worry about timings.
Comment 161•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #157)
::: mail/test/browser/account/browser_accountOrder.js
- account => account.key
- Assert.notEqual(curAccountList.join(), prevAccountList.join());
- // Moving the account down, back to the starting position.
- EventUtils.synthesizeKey("VK_DOWN", { altKey: true });
I'd think these require some time to make sure the event was actually acted
upon, like await new Promise(resolve => setTimeout(resolve));
Same for VK_UP above
That would be odd, since synthesize key seems for moving through a data table and wouldn't involve an actual key
being pressed. Even if it does generate output, it's intermediate output that the user wouldn't usually be
interested in.
- if (!localFoldersAccountKey.IsEmpty() && !lastFoldersAccountKey.IsEmpty() && lastFoldersAccountKey == localFoldersAccountKey) {
- m_accounts.InsertElementAt(m_accounts.Length() - 1, account);
- mAccountKeyList.ReplaceSubstring(localFoldersAccountKey, lastFoldersAccountKey);
This could go wrong, e.g. for key2, key22 would get replaced.
It's probably best to instead look through the accounts again after the
modifications, and create the mAccountKeyList from the list of values.
It's possible. It depends on how keys are delimited and whether or not partial matches are supported. Otherwise there should be a way to specify the entire substring value, i.e. in a key like "xxyz.keyNNN.foo", will it do partial field replacement or does the substring have to line up
to the value between "dots" (in that example).
(In reply to Alessandro Castellani (:aleca) from comment #160)
Using mc.sleep(0) as we are using it with EventUtils.synthesizeKey at various places.
I did implement some
mc.sleep(0)
in the past but they ended up biting me after a while.
It's better to not set an arbitrary timeout ... so we don't have to worry about timings.
Isn't '0' a special value (not arbitrary), to mean to not really wait any time unless something else is demanding attention? I.e. it's a signal from a running thread that it could "wait" if something else needs attention, but otherwise, resume execution after checking for higher priority events. It could still generate non-determinant behavior for other reasons, but it certainly shouldn't be in the same class as mc.sleep(X), X!=0.
Comment 162•4 years ago
|
||
(In reply to L A Walsh from comment #161)
That would be odd, since synthesize key seems for moving through a data table and wouldn't involve an actual key
being pressed. Even if it does generate output, it's intermediate output that the user wouldn't usually be
interested in.
What's immediate to an actual user is not necessarily immediate on the code level. Tests easily fail intermittently because events were triggered on one row but weren't handled yet in time for checking the reaction, on the next line.
Isn't '0' a special value (not arbitrary), to mean to not really wait any time unless something else is demanding attention?
It works like setTimeout. So 0 = next event cycle.
Comment 163•4 years ago
|
||
Comment 164•4 years ago
|
||
Comment 165•4 years ago
|
||
Updated•4 years ago
|
Comment 166•4 years ago
|
||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 167•4 years ago
|
||
Corrected unit test failure.
Here unit tests were failing because all the accounts are local but the first account will behave as an actual local account and will be kept last always. Previously, we were not saving the keys in the order but in Javascript, we used a helper function to always keep the local account at the last. Now we are doing it directly through C++ so account keys strings will be also in such order.
Comment 168•4 years ago
|
||
Corrected the mail/test/browser/folder-widget/browser_messageFilters.js test failure.
Comment 169•4 years ago
|
||
Comment 170•4 years ago
|
||
It's reproducible locally, but you have to run the whole dir. So some kind of interaction with another test
./mach test --headless comm/mail/components/extensions/test/browser/
Comment 171•4 years ago
|
||
Comment 172•4 years ago
|
||
Comment 173•4 years ago
|
||
Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/05adf8cffed2
allow changing sort order of accounts. r=mkmelin
Comment 174•4 years ago
|
||
Unfortunately I think we'll need to back this out. The way nsMsgAccountManager::ReorderAccounts rejects the new accounts if the new vs old length is incorrect doesn't work out if one has chat accounts set up. In a test profile I had one other case as well, but that's likely a leftover from some other unfinished patch (server24 - type none - hostname "smart mailboxes").
The effect is that the accounts are only re-ordered as desired in the account settings UI, but the change doesn't really happen.
Comment 175•4 years ago
|
||
Updated•4 years ago
|
Comment 176•4 years ago
|
||
Hello! It doesn't work on TB 78.6.0 on Mac Catalina... Is that normal ?
Thank's, have a nice day.
Daniel.
Comment 177•4 years ago
|
||
@Daniel: It has not been backported to ESR yet. But it looks like it was backed out completely due to some issues. So those have to be fixed first and when everything works, it may be backported to ESR.
Comment 178•4 years ago
|
||
Good! Thank's for the infos.
Nice day,
Daniel.
Updated•4 years ago
|
Assignee | ||
Comment 179•4 years ago
|
||
Assignee | ||
Comment 180•4 years ago
|
||
Hidden accounts include the unified folder account. Further this fixes reordering after an account
is marked as default.
Depends on D108943
Assignee | ||
Comment 181•4 years ago
|
||
Comment on attachment 9192698 [details] [diff] [review]
Bug-244347_change-account-order-14.patch
The second new patch fixes the issues that lead to the backout:
- Fix migration when there are IM accounts in the profile
- Fix reordering when the user has used the unified folders view
- Bonus fix: reordering when setting a default account with IM accounts
Assignee | ||
Updated•4 years ago
|
Comment 182•4 years ago
|
||
Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/800f2782950f
change sort order of accounts. r=mkmelin
https://hg.mozilla.org/comm-central/rev/3643bba90447
Don't filter IM accounts and add hidden accounts to reordering. r=mkmelin
Updated•4 years ago
|
Comment 183•4 years ago
|
||
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 184•4 years ago
|
||
Updated•3 years ago
|
Description
•