TB 52.0.1 doesn't accept accounts order in mail.accountmanager.accounts
Categories
(MailNews Core :: Account Manager, defect)
Tracking
(Not tracked)
People
(Reporter: worm6666, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: addon-compat, Whiteboard: [add-on: Folderpane Tools][addon: Manually sort folders])
Attachments
(3 files, 9 obsolete files)
(deleted),
image/jpeg
|
Details | |
(deleted),
image/jpeg
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
Comment 2•8 years ago
|
||
Comment 4•8 years ago
|
||
Comment 6•8 years ago
|
||
Comment 10•8 years ago
|
||
Comment 11•8 years ago
|
||
Comment 12•8 years ago
|
||
Comment 13•8 years ago
|
||
Comment 14•8 years ago
|
||
Comment 15•8 years ago
|
||
Comment 16•8 years ago
|
||
Comment 17•8 years ago
|
||
Comment 18•7 years ago
|
||
Comment 20•5 years ago
|
||
Sorry for reviving an old thread. I updated the addon for Thunderbird 68 and a lot of people have reported that the behavior is not the one they initially wanted.
Is it correct that all I need to do is:
- stop overriding the default account
- flip the new boolean pref to true to true
- reorder the account order in the "accounts" configuration variable (the one I'm already modifying)?
Thanks,
Jonathan
Comment 21•5 years ago
|
||
I don't think the "new pref" actually exists yet does it? There is a patch on this bug to add it but I don't believe it has actually been accepted into the released code...
Comment 22•5 years ago
|
||
(In reply to Jonathan Protzenko [:protz] from comment #20)
Is it correct that all I need to do is:
- stop overriding the default account
- flip the new boolean pref to true to true
- reorder the account order in the "accounts" configuration variable (the one I'm already modifying)?
Yes, this is correct.
Your addon will set the pref mail.accountmanager.accounts.ordered to true and allow the user to reorder the accounts in the dialog you already have, saving the order in mail.accountmanager.accounts.
The pref mail.accountmanager.accounts.ordered didn't land in Thunderbird yet as there was no user of it. So you need to apply the patch in this bug, modify your addon to use it.
As described in comment 17, the addon couldn't achieve any order of the accounts, only move one account to the top (setting it as default). Using the new pref, you should get the benefit of being able to achieve any order as then TB will skip its internal forced sorting of accounts.
If you report back that it works and does what is needed (changing the order using your addon), we can land the patch in TB.
Comment 23•5 years ago
|
||
Protz, any luck with updating the addon?
(In reply to Jonathan Protzenko [:protz] from comment #18)
If you or someone else
can provide patches to make it no longer depend on STEEL, then I'd most
gratefully merge them in :)
You just convert Application.platformIs* calls to the ones in AppConstants.platform.
Calls to Application.prefs.get() can be replaced by Services.prefs.get*Pref().
Application.console.log() can be replaced by console.log.
Also Application.restart is now BrowserUtils.restartApplication(); from "resource://gre/modules/BrowserUtils.jsm" .
Comment 24•5 years ago
|
||
I was able to confirm the patch works (I've rebased it on the latest revision of comm-central). I need to update my addon to use MailExtensions so I'm thinking of adding new MailExtension API entry points while I'm at it, for this feature.
Is it ok to submit a combined patch set?
Comment 25•5 years ago
|
||
I think so, thanks.
Comment 26•5 years ago
|
||
Here's an extension of your patch, with suitable MailExtension APIs. I have a rewrite of Manually Sort Folders that uses these APIs for sorting the accounts, so things seem to be working fine.
Some remarks:
- I could not force a rebuild of the folder pane, so now Thunderbird needs to be restarted for changes to be taken into account; previously, it was enough to do:
// Force a rebuild of the account tree.
let mainWindow = Services.wm.getMostRecentWindow("mail:3pane");
mainWindow.gFolderTreeView.mode = mainWindow.gFolderTreeView.mode;
but this no longer seems to work. Any advice?
- There were some issues with the schema description, for which I filed bug 1606570, but it's non-blocking
- I designed the MailExtension API to be nicer than just a raw wrapper around the prefs. Let me know what you think.
- I had to set all of the API functions to be async but I don't understand why; is this a requirement of all WebExtensions?
Thanks,
Jonathan
Comment 27•5 years ago
|
||
Comment 28•5 years ago
|
||
Oops, the hunks in folderUtils.jsm and mailnews.js already had r=mkmelin in attachment 8862594 [details] [diff] [review]. But you lost the comment in the C++ file.
Comment 29•5 years ago
|
||
Here's a patch with the C++ comment reinstated. The r? is only for the extra MailExtensions.
Geoff: the API is crafted to i) perform proper input validation to avoid inconsistent states and ii) to prevent clients from doing something nonsensical, e.g. leaving accounts.ordered = false
but still setting the order of accounts (which will not produce the intended results).
Hope this helps.
Updated•5 years ago
|
Comment 30•5 years ago
|
||
Comment 31•5 years ago
|
||
Thanks for the good review. I'll submit an updated version shortly.
Comment 32•5 years ago
|
||
This patch takes into account all review comments and I was able to confirm that the API works and can be driven from an addon.
I have documented that this function is really two APIs in one, but that the behavior differs on whether the argument has length 0 or not.
ESLint said: ✖ 0 problems (0 errors, 0 warnings)
My SSH access to push to comm-central expired years ago, so if the patch looks good, I'll need someone to put in the landing queue for me.
Thanks,
Jonathan
Comment 33•5 years ago
|
||
Comment 34•5 years ago
|
||
Thanks for the review.
I think it would be nice to order any missing accounts in the default way
before adding them back to the list.
The API demands that all accounts returned by browser.accounts.list()
be present in accountIds
; this leaves in the "missing" accounts list only those that have been discarded by accounts.list()
, i.e. IM accounts, which don't appear in the folder pane. Why does the order matter?
Nit: still missing curly brackets.
ESLint seemed happy with this file. Is there another set of guidelines that I should follow?
I'll fix the other two points.
Comment 35•5 years ago
|
||
ESLint seemed happy with this file. Is there another set of guidelines that I should follow?
Ah that was in the other file and this came from Aceman's original patch. I can re-format that file but I suspect it'll generate a big diff, so I'll just add curly braces.
Comment 36•5 years ago
|
||
You were right that setOrder
accepts any subset of accounts -- I think I used to enforce that all accounts returned by list()
be passed to setOrder
, but this patch no longer does.
All other things have been fixed.
Comment 37•5 years ago
|
||
Comment 38•5 years ago
|
||
(In reply to Jonathan Protzenko [:protz] from comment #36)
You were right that
setOrder
accepts any subset of accounts -- I think I used to enforce that all accounts returned bylist()
be passed tosetOrder
, but this patch no longer does.
OK, I see you accumulate accounts not in the accountIds array in the 'missing' array and then tack them on the tail of the list. That could work, just document it. But still check accountIds for invalid account ids.
(In reply to Jonathan Protzenko [:protz] from comment #26)
Some remarks:
- I could not force a rebuild of the folder pane, so now Thunderbird needs to be restarted for changes to be taken into account; previously, it was enough to do:
// Force a rebuild of the account tree.
let mainWindow = Services.wm.getMostRecentWindow("mail:3pane");
mainWindow.gFolderTreeView.mode = mainWindow.gFolderTreeView.mode;
but this no longer seems to work. Any advice?
Reading 'set mode(aMode)' function, it is not apparent why this woudn't work. There is no check if you are setting the same mode again, preventing rebuild.
Can you try mainWindow.gFolderTreeView._rebuild() just to see if that works?
Comment 39•5 years ago
|
||
(In reply to Geoff Lankow (:darktrojan) from comment #33)
I've played with this a little bit. It's a real shame that a restart is
required to update the order. It shouldn't be too difficult to re-order
m_accounts when the prefs change, but that's probably a story for another
bug.
It does look difficult using existing methods. Tearing down all the accounts (firing all the observers) and then re-reading the pref seems to be very unsafe.
I think we would have to add a special method for this, that just silently re-reads the pref and reorders m_accounts internally, without exposing that this happened to any UI/listeners/observers.
@@ +102,5 @@
// Don't forget to preserve the accounts that are not returned by list
// above.
Services.prefs.setStringPref(
"mail.accountmanager.accounts",
accountIds.concat(missing).join(",")
I think it would be nice to order any missing accounts in the default way
before adding them back to the list.
No, the "default way" is only ordered in the UI (allAccountSorted() function). The mail.accountmanager.accounts pref contains the accounts basically in the order they were created and we do not need to touch that. It is correct if here we append the missing accounts in the same order they already are in mail.accountmanager.accounts. The setOrder() function just pops some out to the front of the list, but the rest should stay in the order they are (like a stable sort).
Comment 40•5 years ago
|
||
(In reply to :aceman from comment #37)
Could this also check if all ids in accountIds actually exist in
MailServices.accounts.accounts ?
And also that accountIds does not contain less account ids than there exist
in MailServices.accounts.accounts ?
Basically accountIds must be a permutation of ids in
MailServices.accounts.accounts, not a smaller subset. Otherwise accounts
will get lost from the profile.
Also check if any passed in account id isn't in the list twice.
I wonder if we should better pass the list to some method of nsIMsgAccountManager that validates it properly and re-initializes m_accounts instead of having some random JS code (albeit in the WE api) manipulate the mail.accountmanager.accounts pref directly possibly clashing with account manager's idea of it.
Comment 41•5 years ago
|
||
I'll fix the documentation and force a restart after setting the accounts.
The code already errors out if i) some accountId is duplicated or if ii) some accountId is invalid. After the loop has run, unique
contains the set of all accounts that have been found in accountIds
and that are valid. If there's less elements in the set than accountsIds.length
, either there's a duplicate or some accountId is invalid.
Setting this in C++ seems like a tremendous amount of work that will be less maintainable in the future, so I'm inclined to just stick with the WebExtension API.
Thanks for the review!
Comment 42•5 years ago
|
||
For the record I tried _rebuild
as well and couldn't get it to work. I couldn't figure out why, but we can always improve the API later and skip the restart.
Comment 43•5 years ago
|
||
(In reply to Jonathan Protzenko [:protz] from comment #41)
Setting this in C++ seems like a tremendous amount of work that will be less maintainable in the future, so I'm inclined to just stick with the WebExtension API.
I think there could be both, the WE API allowing to specify only some accounts and then fills in the rest, also manages the mail.accountmanager.accounts.ordered pref, and then the C++ method that takes the final list, does some sanity checks (which then wouldn't need to be in the WE API) and reorders accounts in the nsIMsgAccountManager, saves the pref and thus avoids the need of the restart.
(In reply to Jonathan Protzenko [:protz] from comment #42)
For the record I tried
_rebuild
as well and couldn't get it to work. I couldn't figure out why, but we can always improve the API later and skip the restart.
May depend on what exactly you have tried. Changing the order of the accounts couldn't work (rebuild even if working didn't change the appearence) as the account manager didn't change its internal order of the accounts after you just call setOrder() in the WE API. Only the change to mail.accountmanager.accounts.ordered value could be picked up by the tree rebuild.
Comment 44•5 years ago
|
||
Comment 45•5 years ago
|
||
I've added a patch taking into account your comments. I would suggest landing this first, then I'm happy to open a new bug for the C++ side of things that will eventually allow skipping the restart.
Thanks,
Jonathan
Comment 46•5 years ago
|
||
Comment 47•5 years ago
|
||
(In reply to :aceman from comment #46)
Why are you changing this to return the sorted list?
Wouldn't both variants be useful to addons?
An unsorted list can happen to be sorted, so what's the use case for getting an explicitly unsorted list?
Comment 48•5 years ago
|
||
You still didn't document that you can pass less accounts than the full list.
I think that's a corner case and not the intended usage for the API, so I'd rather keep the documentation concise rather than go and explain the operational semantics of the API in the case where not all accounts are passed.
An unsorted list can happen to be sorted, so what's the use case for getting an explicitly unsorted list?
Agreed.
Comment 49•5 years ago
|
||
Comment 50•5 years ago
|
||
Updated•5 years ago
|
Comment 51•5 years ago
|
||
Magnus and I just talked about this and we have decided that a WebExtension should not have the ability to restart Thunderbird. You'll need to either fix the underlying problem or tell the user to restart Thunderbird after making the changes.
I'm surprised by this decision. Looking at https://thunderbird-webextensions.readthedocs.io/en/latest/, my understanding is that since Thunderbird is overhauling its addon system, the Thunderbird team is committing to providing suitable API entry points so that existing addons can continue to provide equivalent functionality. There's even a suggestion to file a bug, so that APIs can be added.
My understanding is also that APIs should provide well-designed functionality. Here, :aceman explicitly pointed out the danger of not restarting Thunderbird:
(In reply to :aceman from comment #37)
I'm not sure how safe this is as the pref will be saved again by the account manager backend when accounts are manipulated and that will have its own idea of the order (stored in m_accounts of nsMsgAccountManager.cpp).
Since not restarting Thunderbird is dangerous, two options have been discussed:
i) an extensive fix requiring work on the C++ and JS sides, and
ii) a safe workaround based on a restart (see comment #37).
The first one is out of scope for me: I am no longer a Thunderbird module owner, and I'm only trying to keep the 4-th most popular addon (200,000 active daily users) alive, since I'm getting emails in my inbox every day. I have very limited cycles to spend on this (I am no longer in grad school!).
The second one seems like a fine temporary thing: it's not a general-purpose restart API, but a temporary quirk of behavior that will be fixed the day the Thunderbird team overhauls the setOrder
API to no longer require a restart.
Declining both i) and ii) means that you're asking the addon to be aware of a severe flaw in the API, and as such, to display a big large banner after every change saying "everything will be unsafe unless you restart Thunderbird now". While I understand that you don't want to expose restart functionality to addons, I would very strongly advocate for ii) to be implemented for now, and for this restriction to be lifted once a Thunderbird-side fix can be devised.
What do you two think?
Comment 52•5 years ago
|
||
I think it's simply the case that if we don't have a backend that can handle something properly, we shouldn't expose an API for that until we do.
But, I'm not sure fixing the backend would necessarily be too hard.
Comment 53•5 years ago
|
||
What are the implications for https://addons.thunderbird.net/en-US/thunderbird/addon/just-restart_tb68 (I favorite of mine)
Comment 54•5 years ago
|
||
Not doable as an MailExtension.
Comment 55•5 years ago
|
||
Right, it may be hard using existing methods, but if we are allowed to make a new method that notifies the account manager of the change, it could work.
Protz, please try the attached patch and from your new function setOrder() call MailServices.accounts.reorderAccounts(finalList) instead of setting the mail.accountmanager.accounts pref and restarting. The finalList is the array you construct from accountIds and missing arrays concatenated. It should contain all existing accounts. You can keep managing mail.accountmanager.accounts.ordered in setOrder exactly as it is.
You still need to force refreshing the folder pane, but maybe now the foldertree.mode = mode could work.
Comment 56•5 years ago
|
||
(In reply to :aceman from comment #55)
Protz, please try the attached patch and from your new function setOrder() call MailServices.accounts.reorderAccounts(finalList) instead of setting the mail.accountmanager.accounts pref and restarting. The finalList is the array you construct from accountIds and missing arrays concatenated. It should contain all existing accounts. You can keep managing mail.accountmanager.accounts.ordered in setOrder exactly as it is.
You still need to force refreshing the folder pane, but maybe now the foldertree.mode = mode could work.
This worked as advertised and now a restart is no longer needed. Thanks very much!
Comment 57•5 years ago
|
||
Here's a combined patch that has all the changes in. I was able to confirm via the addon that this has the desired effect and merely setting the mode property of the folder tree view refreshes the UI.
Thanks very much Aceman for a most helpful patch!
Geoff, I've requested another review -- I feel like this patch has the potential to make everyone on this bug happy :)
Comment 58•5 years ago
|
||
I started reviewing this and kept thinking how badly it needed a test … ended up just writing a test. So here's that test and the changes I was going to ask for in review. (Interdiff should work.)
There's one thing that seems a bit weird but probably doesn't matter. When clearing the custom order, accounts won't go back into the original order (ie. the order they were created) if they're of the same type, e.g. two IMAP accounts.
R? aceman on the new bits, otherwise it's r+ from me.
Comment 59•5 years ago
|
||
Side note: mozilla::Swap
just got removed in favour of std::swap
so this won't build against the latest m-c.
Comment 60•5 years ago
|
||
Comment 61•5 years ago
|
||
Comment 62•5 years ago
|
||
(In reply to :aceman from comment #61)
Why are you actually sorting the accounts here in any way? Didn't we say we
want to keep the order of the accounts not specified, as it currently is?
If there are accounts are "account1,account2,account3" and you call
setOrder(["account2"]), then we want to get "account2,account1,account3" not
any other sorted order (you could get "account2,account3,account1", if
account3 is IMAP and account1 is Local Folders).
We want to get any remaining accounts in the order they would ordinarily show in the UI. (That is, it should appear as though account2 has been removed from where it is in the list and put at the top and no other changes happened.) Putting the accounts back in numerical order is of no use to the user.
I don't understand what this will contain.
Ugh, the way these tests have to be written is brain-melting. We go back and forth between the extension calling browser.accounts.setOrder
and the main process checking the order is correct. It might be easier to make sense of it if you deal with each part separately, knowing that every time you reach awaitMessage
, the other part does something.
@@ +196,5 @@
- // Reset the order, check that it is reset.
- await extension.awaitMessage("doCheck");
- checkOrder(false, ...testAccountIds);
- // Set a new order with one account missing.
Which account is missing in the check? There are 4 in the call below.
@@ +218,5 @@
- testAccountIds[2],
- testAccountIds[3]
- );
- // Set a new order with faulty data. The order should not change.
What is faulty in the following 3 calls to checkOrder() ? And they also look
identical.
These are the expected orders.
Comment 63•5 years ago
|
||
(In reply to Geoff Lankow (:darktrojan) from comment #62)
We want to get any remaining accounts in the order they would ordinarily show in the UI. (That is, it should appear as though account2 has been removed from where it is in the list and put at the top and no other changes happened.) Putting the accounts back in numerical order is of no use to the user.
I think you achieve this also when keeping the order in the pref as it is. If mail.accountmanager.accounts.ordered was true before and after the call to setOrder with 1 account, then it should happen what you say. If it was false and is now true after the call, then yes, the order will totally change in the UI, but I don't think the expectation is that the 1 account gets to the top and the others are unchanged in the UI at the expense of totally reordering the pref. Where did we agree on that?
I did not propose numerical order in this case, just that the given account is moved to the front in the pref and others are left as they are, in the pref, not in the UI.
This is basically a question for Protz on what the API should do, what is useful for the addons.
(In reply to Geoff Lankow (:darktrojan) from comment #58)
There's one thing that seems a bit weird but probably doesn't matter. When clearing the custom order, accounts won't go back into the original order (ie. the order they were created) if they're of the same type, e.g. two IMAP accounts.
Yes, we do not store the original order anywhere yet so we can't restore it on setOrder(null). But sorting the existing account ids in numerical order (the number after 'account' string) would basically restore them to the order of creation that we normally have.
Comment 64•5 years ago
|
||
That makes sense except for the fact that you're then displaying the accounts to the user in the order set. Order of creation doesn't mean a lot to the user.
Comment 65•5 years ago
|
||
Of course not. By default we never show the order of creation (even though it is in the pref) and reorder the accounts in the UI with the compareAccounts algorithm. But when an addon turns off this default algo, it is a question what it wants to do. Originally I let it freely do and manage the whole pref and that would be honored in the UI. Now when it is possible to call setOrder with only a subset of accounts, it needs to be specced out how the rest of them will be ordered. But I would not be against the current reordering with compareAccounts, if you add the resetting to numerical order on setOrder(null). As that is where the user started before messing with the order.
Comment 66•5 years ago
|
||
I think this API is good as it is and would advocate for it being merged.
- The question of what happens when calling
setOrder()
without any argument is the important one, and I believe it the code as it is ensures that the accounts are reset to the default sort order, which is what we want. - I will always provide all the accounts, never a subset of them. So, let's not pay too much attention to what happens when only a subset of the accounts is passed -- I believe it's totally irrelevant and if any future addon (not mine) disagrees about the API's choice for the accounts that are missing from the argument list, they can always provide more account-ids to enforce a given sort order.
Comment 67•5 years ago
|
||
Worded differently: I would love for this to be merged now so that I can start pointing people who write to me daily to an alpha build of my addon telling them to use Thunderbird Daily or wait for the next release.
Updated•5 years ago
|
Comment 68•5 years ago
|
||
Comment 69•5 years ago
|
||
Thanks for the review, Magnus!
Looks like you'd run into this for the IM account case? For that, unique and accountIds would be different size
This test works fine in the presence of an IM account. It only catches two cases: caller passed duplicate accountIds, or caller passed an accountId that corresponds to no known account. Geoff, can you confirm that this is covered by your tests?
I don't quite like that there'd be two ways to sort. The grouping by account type is a bit odd I think: the order the account were in the list makes more sense, and then if the default is changed, we could just move that to the top of the account ids in that list. Then we should just otherwise too allow rearranging the order by dnd
The scope of this bug is exclusively to provide a MailExtension API entry point for "Manually Sort Folders", currently the fourth most-popular addon with 200,000 users, so that it can keep working with future versions of Thunderbird. From what I read on MDN, the process is that if some API is missing, addon authors can ask for new MailExtension APIs to support their use-cases. Rather than just asking, I worked out a prototype patch, which was then improved tremendously by Geoff and Aceman. We then reached consensus on what the API should look like. The API is sound (addons cannot break the internal invariants), it has no effect on the default behavior of Thunderbird, and 100% foots the bill for the purposes of what my addon needs.
I understand and appreciate that having a built-in solution would be much better, but to me this means opening up a different bug, and finding someone ready to commit the cycles and make this a built-in feature of Thunderbird. In the meanwhile, landing an API we reached consensus on would i) allow me to move on to other missing MailExtension APIs that my addon needs, ii) provide a great way to keep a very popular addon working and iii) would, I believe, be very much in the spirit of what MailExtensions are meant to be.
Thanks!
Comment 70•5 years ago
|
||
Comment 71•5 years ago
|
||
This isn't substantially different from the previous patch but it does fix the review comments.
Comment 72•5 years ago
|
||
(In reply to Jonathan Protzenko [:protz] from comment #69)
The scope of this bug is exclusively to provide a MailExtension API entry point for "Manually Sort Folders", currently the fourth most-popular addon with 200,000 users, so that it can keep working with future versions of Thunderbird. From what I read on MDN, the process is that if some API is missing, addon authors can ask for new MailExtension APIs to support their use-cases.
That's true but I guess we should just fix bug 244347.
The problem with adding a pref to do a special behaviour is that then correctly fixing bug 244347 would be much harder.
Comment 73•5 years ago
|
||
Comment 74•5 years ago
|
||
Thanks Magnus for your feedback.
I would like to confirm what you are suggesting:
- always observe the order of accounts in
mail.accountmanager.accounts
, i.e. get rid of the current behavior which is to group accounts by type; this entails getting rid of theordered
pref - add new code to change that order when the default account is changed, so that the default account makes it to the top of the list
- keep the API entry point for my addon to allow users to arbitrarily reorder accounts.
:aceman and Geoff, what are your thoughts?
I am fine with the three points above -- I don't believe bug 244347 will be fixed anytime soon (it's 16 years old), but the three points above will allow my addon to continue to work, and people will have a way through the addon to edit the sort behavior if they are so inclined.
Thanks,
Jonathan
Comment 75•5 years ago
|
||
I see Magnus suggested to use tree._rebuild(). I'm not sure I'm happy about that, whether the addon does not peek too much into the internals. Yes, that would be fine in the past, but today Mozilla pretends the addons are not supposed to do that and isolates them in WE as much as possible.
I'm not sure Magnus proposed to drop the automatic ordering of accounts by type (added in bug 749200) and using the pref order directly.
Implementing bug 244347 in TB would mean to add much of the UI the addon currently has to TB. Nobody has decided on that yet. Maybe that would be worth for 200000 users, more rarely used features got implemented already.
Also, dropping the patch as it is and reworking it as you proposed would probably render it unusable for TB 68 due to higher risk for all users, not just the addon users.
Comment 76•4 years ago
|
||
Hi Magnus, can we try to recap where we stand on this bug?
My impression is that aceman and I both agree that fixing the underlying bug 244347 is not feasible and that we should try to get an addon solution to this for the time being. Do you concur?
Regarding the point of not having a supplemental pref -- as aceman says, this is quite risky and risks changing the default behavior for users, knowing that they are notoriously conservative on this. I like the idea of having a flag that guarantees that nothing changes and that no user is upset, then the flag can be activated via the addon. We can always refine later and get rid of the flag, I see nothing that prevents a future simplification from happening. Thoughts?
Thanks,
Jonathan
Comment 77•4 years ago
|
||
Why is fixing bug not feasible? I've actually commented there earlier today. The plan is to fix that now.
Comment 78•4 years ago
|
||
That sounds great, I'll let the Thunderbird team fix the underlying bug then, and will update my addon page to say that the account sorting functionality is no longer available as the Thunderbird team plans on implementing it soon, with a link to bug 244347.
Are there similar plans to allow sorting folders in the folder pane? This is the main functionality of my addon, so if Thunderbird is adding reordering of accounts now as a built-in feature, perhaps it should implement reordering of folders too.
Thanks,
Jonathan
Comment 79•4 years ago
|
||
No plans to allow sorting of folders. That sound like something well suited for an (your) add-on to provide.
Comment 81•3 years ago
|
||
Yes this should no longer be relevant after we fixed bug 244347.
Updated•3 years ago
|
Comment 82•3 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #81)
Yes this should no longer be relevant after we fixed bug 244347.
Please reopen, fix this bug independent from bug 244347 and backport it to version 78.
Background: On Ubuntu and maybe elsewhere the current version of TB is 78. Normally it takes a long time (~2 years), that Ubuntu includes a new version of TB.
The GUI to manage this preference can wait until that, but in the meantime it would be helpful for users, if manually changing the preference would have success.
Comment 83•3 years ago
|
||
See also:
Bug 244347 comment 92 (last paragraph)
Bug 244347 comment 112
Comment 84•3 years ago
|
||
Normally it takes a long time (~2 years), that Ubuntu includes a new version of TB.
I think that may be a bit exaggerated. The update from 68 to 78 was indeed delayed on Ubuntu very long (about 8 months) due to some technical difficulties on the Ubuntu side, but the upgrade to TB91 will go more smoothly I guess.
Comment 85•3 years ago
|
||
Correct, 78 is end of life from start of November. There's no backporting of anything non-crucial (security, or potentially some crashfix) anymore.
Comment 86•3 years ago
|
||
(In reply to Ulf Zibis from comment #82)
Please reopen, fix this bug independent from bug 244347 and backport it to version 78.
Hello Ulf, thanks for your input and requests. I understand your wish, but unfortunately, it's not possible.
Comment 85 is clear, and imo it's a decision based on good reason. Looking at the struggle to implement bug 244347, there's really no way we could invest resources into backporting that to TB78 shortly before EOL and risk regressions there. To get the most out of your software, you need to upgrade to the current version. That's just how it is!
Ubuntu update cycles are beyond our control, but will only affect a minority of users.
(In reply to Magnus Melin [:mkmelin] from comment #85)
Correct, 78 is end of life from start of November. There's no backporting of anything non-crucial (security, or potentially some crashfix) anymore.
Comment 87•3 years ago
|
||
Bug 244347 has implemented the pref which is topical here: mail.accountmanager.accounts.
UI: DnD in account manager.
Description
•