[autoconfig] Status area goes blank while running guess config
Categories
(Thunderbird :: Account Manager, defect)
Tracking
(thunderbird_esr68 fixed, thunderbird72 fixed, thunderbird73 fixed)
People
(Reporter: BenB, Assigned: mkmelin)
References
Details
Attachments
(3 files, 17 obsolete files)
(deleted),
patch
|
mkmelin
:
review+
aleca
:
ui-review+
jorgk-bmo
:
approval-comm-beta+
jorgk-bmo
:
approval-comm-esr68+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
mkmelin
:
review+
mkmelin
:
ui-review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
mkmelin
:
approval-comm-esr68+
|
Details | Diff | Splinter Review |
Reproduction:
- Open Thunderbird account creation dialog
- Enter abc@outlook.co.uk as email address (must be domain "outlook.co.uk", not a domain that is in the ISPDB)
- Continue
Actual result:
- First, you'll see the status messages how the different autoconfig methods are being tried.
- Then, the status area goes completely blank, for several seconds. (During this time, TB tries its "guess config" heuristic of trying common server names.) As a user, you're confused whether that's a bug, or whether you should start over, or what.
- Then, the warning "failed to find the settings" appears and you see the manual config mode.
Expected result:
Result step 2 should not exist. Instead:
- First, you'll see the status messages how the different autoconfig methods are being tried. The "guess config" is just the last line of the autoconfig method statuses.
- Then, the warning "failed to find the settings" appears and you see the manual config mode.
Comment 1•5 years ago
|
||
This happens in 60 and 68 as well, it seems it always behaved like this, which indeed is weird and need to be fixed.
It also shows the "Your Login:" field.
Not a regression, but definitely need to be fixed.
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Comment 2•5 years ago
|
||
What's even more weird is that it works for abc@uncommon.com . It fails reproducibly for abc@outlook.co.uk.
On the Dev Tools console, I see "UI mode start" before the guess config attempts happen. This is the bug, but I don't know why we enter the UI mode "start".
Comment 3•5 years ago
|
||
This is a possible solution to the problem.
If the Exchange username is required, the wizard shows that field and keeps the autoconfig message visible, until we find or don't find a configuration for it.
Is this clear enough?
I'm not sure if this workflow is intuitive and simply showing the "Your Login:" field is understandable enough.
Also, is it worth continuing to search for the configuration if we don't have the proper login info?
Maybe we should stop that and show a more eloquent message to the user when showing the login field.
Reporter | ||
Comment 4•5 years ago
|
||
is it worth continuing to search for the configuration if we don't have the proper login info?
Yes, it is. For Office365, if the user has legacy protocols and password-based auth disabled, not even AutoDiscover will work, because (sadly) it needs a password. However, for Office365 domains, we can find the config from ISPDB. Then, after the user confirmed, Owl can then open a login window and we're logged in. So, the ISPDB allows us to jump over this hole, in this particular Office365 case.
Assignee | ||
Comment 5•5 years ago
|
||
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Comment 6•5 years ago
|
||
Comment 7•5 years ago
|
||
Certainly ;-)
Comment 8•5 years ago
|
||
I doubt this patch can break something as it doesn't affect anything other than keeping the autoconfig message visible.
The real issue here, as pointed out by Magnus, is the lack of proper feedback to the user when we need/ask for the login on an exchange account.
Anyway, I'll put this on the backburner until there's more clarity on what to do.
Comment 9•5 years ago
|
||
The issue reported on this bug is purely from a UX point of view, which is the config message disappearing while there's still a check running in the background.
The submitted patch fixes the issue and doesn't change anything in the currently running code.
I think we should land this as it improves the usability in this scenario, and then open a follow up bug to fix any AutoDiscovery issue there might be.
Reporter | ||
Comment 10•5 years ago
|
||
Hi aleca, sorry for the lack of response. I had to put out fires at other places. I hope to get to the review in the next 1-3 days.
Reporter | ||
Comment 11•5 years ago
|
||
The problem is that the config process needs the login, and the server doesn't use the email address as username. So, the login field is required even to find the right config.
I tested this and this patch doesn't work as expected for the intended use case. Try abc@medma.uni-heidelberg.de . You will see a config from the email provider, but that config is broken and not the right one. And the "Your login:" field appears at the same time, but it's very easy to miss. This config result distracts user focus away from the "Login" input field. But that field needs to be filled out in order to get the correct config from the server. Given that another config result shows, the user will likely miss that input field. That's what the start mode line was for.
Worse, the "Done" button is enabled. Even if the user enters a username, there's no way to restart the config process. That is another reason why we need to go back to the start mode.
Looking more at the code, there's a comment a few lines up saying: Must call error callback in any case to stop the discover mode.
. That's the actual bug. This doesn't work as intended. The discover mode is not stopped on all errors (because errors from config methods are completely normal), but only when CancelledException
is thrown. Furthermore, the old code took only the exception from the first config method into consideration. I fixed both, and now it works.
Reporter | ||
Comment 12•5 years ago
|
||
Comment 13•5 years ago
|
||
Reporter | ||
Comment 14•5 years ago
|
||
Hey aleca, thanks for the positive feedback. Would you like to iterate based on my patch and build on it? If so, feel free to do so.
Reporter | ||
Comment 15•5 years ago
|
||
Probably a simple way to fix both birds with one line of code is to display a status message with your explanation when we go to show the username field. It would probably also override the "Looking up configuration..." message.
Comment 16•5 years ago
|
||
Yes, I can implement the message based on your patch, no problem.
What do you think about this?
"A Username is required to complete the login process."
Very short and easy to understand.
Reporter | ||
Comment 17•5 years ago
|
||
"A Username is required to complete the login process."
That's good - simple and precise, yes. I like it! :-) 2 nits corrected:
"A username is required to complete the configuration process."
Comment 18•5 years ago
|
||
This should do it.
Reporter | ||
Comment 19•5 years ago
|
||
Reporter | ||
Comment 20•5 years ago
|
||
Try whether
this.stopSpinner("username_required")
works.
If for some reason that doesn't work, then showErrorStatus()
is fine, too.
Comment 21•5 years ago
|
||
Thanks for the feedback.
We need to use the showErrorStatus()
method otherwise the message area will show a green checkmark, which is misleading.
This message will also appear if the user adds an incorrect username, so it makes sense being an error.
Reporter | ||
Comment 22•5 years ago
|
||
Assignee | ||
Comment 23•5 years ago
|
||
Reporter | ||
Comment 24•5 years ago
|
||
Magnus, this fix is correct. Please see bug 1599029 comment 5.
Updated•5 years ago
|
Comment 25•5 years ago
|
||
Assignee | ||
Comment 26•5 years ago
|
||
Indeed, but I have a feeling trying to get by without proper error feedback messages is what got this into the current state to begin with.
Reporter | ||
Comment 27•5 years ago
|
||
Not a problem. For TB 68, we can just remove the line this.showErrorStatus("username_required");
and the string. That was just nice sugar added. Just showing the username field on its own is sufficient.
Reporter | ||
Comment 28•5 years ago
|
||
There is no error at this point yet. We just detected that we don't have enough information. For most servers, the email address matches the login username, but not so for Exchange servers, and we detect this specific situation and ask the user to enter the username.
In fact, this is similar to the other 3 fields.
Even if the user entered a username and the login fails, it's still most likely that the username form is wrong (because there are so many variants how to write the username, and they are different on each system) and not the password (which is always the same, and he can even display it with the little icon button that aleca helpfully added).
Assignee | ||
Comment 29•5 years ago
|
||
Reporter | ||
Comment 30•5 years ago
|
||
In general the patch looks like it would do almost the right thing.
Thanks.
I think bug 1598861, and bug 1599029 should land first so that the whole process makes some sense (and doesn't bitrot each other).
In bug 1599029, it's not even clear what happens, and the issue there is clouded by the bug here, so this here needs to land first.
This here is a clear bug, and has a fix since quite a while, and the fix is correct.
What IS wrong, is the error message.
The error message is correct, for the given situation. We know that this is an Exchange server, and their standards configuration uses usernames different from the email address, so the username is the problem in almost all cases. We know the user just needs to enter the username.
You might argue that if the user did enter a username and we still get an error, then we can infer that the password might be wrong. But in reality, there are so many different forms of usernames, and there is only one password, that even if the user entered a username, and login fails, the most likely reasons is still the username and not the password. Please see bug 1599029 comment 33 for experiences from the field, where admin cites evidence and actual logs that people needs several attempts to get the username right, even with hints what the right form is.
So, I maintain that the error message is exactly right. It was created by aleca with input from me.
For 68? Either skip the message
Agreed.
Reporter | ||
Comment 31•5 years ago
|
||
I like the error message, I think it's helpful exactly as it is, but if that helps the landing, I suggest remove the message for now. It wasn't there before and is not required to fix the bug. It's just additional niceness.
Assignee | ||
Comment 32•5 years ago
|
||
(In reply to Ben Bucksch (:BenB) from comment #30)
The error message is correct, for the given situation. We know that this is an Exchange server, and their standards configuration uses usernames different from the email address, so the username is the problem in almost all cases. We know the user just needs to enter the username.
Please look at what I wrote. The username might be there already.
Anyway, just re-read what you wrote and apply it to context of O365 (and the other free MS account). There is no username needed. Just the email. 401 == wrong credentials, or other trouble.
Reporter | ||
Comment 33•5 years ago
|
||
Please look at what I wrote. The username might be there already.
I saw what you wrote. See bug 1599029 comment 37 (where you wrote this).
just re-read what you wrote and apply it to context of O365 (and the other free MS account). There is no username needed. Just the email. 401 == wrong credentials, or other trouble.
Yes, I can see your point for this case. Let me think about that.
Reporter | ||
Comment 34•5 years ago
|
||
just re-read what you wrote and apply it to context of O365 (and the other free MS account). There is no username needed. Just the email. 401 == wrong credentials, or other trouble.
Yes, I can see your point for this case. Let me think about that.
I've just tried this, and it worked just fine for me. With this patch here, and an Office365 account, the ISPDB result was used, and no username field appeared, no matter whether the correct password or a wrong password is used.
Reporter | ||
Comment 35•5 years ago
|
||
This is the same as the last patch, but without status message. We simply show the username field.
Reporter | ||
Comment 36•5 years ago
|
||
Assignee | ||
Comment 37•5 years ago
|
||
Reporter | ||
Comment 38•5 years ago
|
||
we should really change this to be function(errors)
The signature of all errorCallback
s is that the first parameter is the exception. That's the rule for all functions here. You cannot just suddenly change the type. That would confuse everybody and surely lead to bugs.
But I can remove the allErrors
check, yes. That makes the code nicer.
Reporter | ||
Comment 39•5 years ago
|
||
Reporter | ||
Comment 40•5 years ago
|
||
During self-review, I saw that I could use some()
instead of find()
. Fixed.
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Comment 41•5 years ago
|
||
Use existing onStartOver()
function. Makes it cleaner.
Compare also bug 1600954, which goes along with this patch.
Comment 42•5 years ago
|
||
Comment 43•5 years ago
|
||
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 44•5 years ago
|
||
Assignee | ||
Comment 45•5 years ago
|
||
Going to land it, but let's keep open to add a proper message too while we wouldn't backport that.
Comment 46•5 years ago
|
||
Comment 47•5 years ago
|
||
Any chance to land patches with correct commit messages in the future? :-( :-(
Reporter | ||
Comment 48•5 years ago
|
||
@Magnus: Thanks for having landed this!
Comment 49•5 years ago
|
||
Please submit a second part to re-introduce the message. Alex called the current behaviour "super weird" in comment #42.
Comment 50•5 years ago
|
||
Here's the missing error message. I tried setting up jk@aalto.fi with incorrect credentials and that gives an appropriate message. So I think this text is correct. I'm open to a better wording.
I don't understand why I have to do this during my leave, though :-( :-( :-(
Comment 51•5 years ago
|
||
Assignee | ||
Comment 52•5 years ago
|
||
Like I said earlier, there are two cases so I don't see why we wouldn't display the different cases differently. I'll attach a patch and screenshots
Assignee | ||
Comment 53•5 years ago
|
||
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 54•5 years ago
|
||
Assignee | ||
Comment 55•5 years ago
|
||
Comment 56•5 years ago
|
||
Comment 57•5 years ago
|
||
Assignee | ||
Comment 58•5 years ago
|
||
It's slightly wordy, but we do have plenty of space. For AD, yes that is active directory. In reality, I do think that is what almost everyone is using as the "domain". That is, you will have the username be "AD\example" - so that's why I wouldn't write out fully what it is. I should add a l10n note about it though.
Reporter | ||
Comment 59•5 years ago
|
||
Remember that we target end users who are not in the computer business. They don't know what "Active Directory" or "AD" is.
However, they do know what their "Windows login" or "Windows domain login" is. An example is also critically important, to show the format of the username, and the example should be as concrete as possible, e.g. "COMPANY\you".
I concur with Alex' comment 16 that the message should be as short as possible. More explanations are worse. Just say what we expect from the user, and give a very concrete example of the username form.
I suggest:
"A username is required to complete the configuration process. This is typically your Windows domain login, e.g. "COMPANY\you". Please also verify your password by clicking on the eye icon."
This is concrete, with instructions. It's still longer than I would like.
Contents:
- The standard configuration of an on-premise Exchange server is to use the Windows domain login as username, and the email address does not work. So, the primary message here should be to enter the username, and not that the login failed.
- I am adding a concrete example of the username, because the concrete form and spelling of the username - e.g. "" vs. "/" vs "." is what causes most of the login failures.
- For the rare case that the password is wrong, I added the phrase.
- I don't think we need to mention to check the email address, because that's going to be obvious, as it's displayed and right next to the password. If the user checks the password, they will also see when the email address right above it is wrong.
Comment 60•5 years ago
|
||
Ben: Magus suggested to have two different strings. What you think about that?
First:
A username is required to complete the configuration process. This is typically your Windows domain login, e.g. "COMPANY\you". Please also verify your password by clicking on the eye icon.
Second:
Please verify your username and password by clicking on the eye icon.
Assignee | ||
Comment 61•5 years ago
|
||
Ignoring the password wrong case doesn't make any sense since that's easily even half the times especially if you have a more complex password.
Anyway, I've made some adjustments to make the message more clear. All the domain names I ever saw were actually named AD so I think it's reasonable to assume it's a very common domain name. (Probably the default in some setup?) If something else is actually used, the placeholder text would still guide you right.
Assignee | ||
Updated•5 years ago
|
Reporter | ||
Comment 62•5 years ago
|
||
Remember that the standard config of on-premise Exchange servers (which is what we're talking about here) is to use a username completely different from the email address. That's not a user error, but all users will get this prompt.
For on-premise Exchange, it's typically the Windows domain login, e.g. EXAMPLE\mjola .
In my first hand experience, and that's substantiated with logs from admin (see bug 1599029 comment 33), users have a really hard time to find the right form of username, because there are so many different forms of username for the same user, depending on the system used. It could be:
- mjola
- michael.jola
- michael.jola@example.com or
- EXAMPLE\mjola
Good luck finding the right one. You can't really know for sure.
OTOH, there is typically only a single password in all cases (and the user can verify it easily with the eye button).
In reality, many companies have various different forms of usernames for various systems, and most users have no clue what the right username form is in this particular case. If the username was obvious, then I would agree with you. But the reality is different.
So, no, I do not think that "password wrong" is a typical case. Even if the user entered a username, and we fail the second time, it's still most likely the username that's wrong and not the password.
If indeed the username was wrong, and the user thinks that he needs to use a different password, and enters a different, valid password, we not only created a headache and setup pain for the end user, we also made him give up a potentially valuable password to the wrong server. That's a security problem, in addition to user setup pain.
More scientifically, you need to fix one variable at a time. If you ask the user to perpetuate two variables at the same time, you multiply the attempts required.
I don't mind having 2 prompts, but even the second prompt needs to primarily encourage users to find the right username and not the password. The latter would be actively damaging.
Comment 63•5 years ago
|
||
Reporter | ||
Comment 64•5 years ago
|
||
The tooltip wouldn't be prominent enough. It's exactly that part that is the most important and needs to be in the user's face.
It should also be included in the second error message, otherwise it would be gone after the first attempt.
FWIW, the username example should appear as "ACME\johndoe" (single backslash). "ACME" would be nice reference to Coyote and Road Runner, and doesn't need to be translated, but it's less cryptic than "AD" as example.
Reporter | ||
Comment 65•5 years ago
|
||
I think the last patch of Magnus is good, but the error messages are not really good yet.
Rationale: See comment 62.
So, as first error message, I used the one from Aleca in patch 3, plus a concrete example to help the user, with the most likely form of the username.
As second error message, I also ask the user to double-check the password. And expand more on the different forms of username. I kept the concrete examples in there, because that's exactly the info that the user needs to find the right format of username. (I don't ask to check the email address, because that's too obvious, and if it's really wrong, the user will see it once he checks the password.)
I think that captures all concerns, including:
- Magnus: ask user to check password, once we have a username
- Ben: there are many different username forms and it often needs several attempts to find the right one, see bug 1599029 comment 33
- Aleca: short and concise message, to the point
Reporter | ||
Comment 66•5 years ago
|
||
Assignee | ||
Comment 67•5 years ago
|
||
Assignee | ||
Updated•5 years ago
|
Reporter | ||
Comment 68•5 years ago
|
||
You wrote:
this is wrong as previously described
Are you referring to your statement "password wrong case ... that's easily even half the times"? I explained in comment 62 why that is not the true here in this case. I also gave real world data, specifically for this case here, to back that up.
Sorry, I don't understand why my patch is "wrong", given that I captured your concern to ask the user to check the password.
Your text does not consider the reality of Exchange servers.
I really felt like the patch captured everybody's concerns.
Comment 69•5 years ago
|
||
How long do you want to go around in circles here leaving the product broken in the meantime? In bug 683809 for example we're up to comment #129 and the thing has been blocked for more then three years now.
Personally, I think that both suggestions presented here s*ck. Magnus message is way too long and AD active directory is a M$ technology that has little to do with the concept of a domain in the M$ sense, at least that was the case when I was on M$ decades ago. I don't know what's wrong with <!ENTITY usernameEx.placeholder "YOURDOMAIN\yourusername">
or just using domain.
How about stopping r- each others patches superseding them when all we need is to agree on a text in a COMMENT before turning this into a patch. It's really sad that I can't enjoy my hard earned PTO and need to intervene on Kindergarten stuff like this :-( :-( :-(
Comment 70•5 years ago
|
||
Comment 71•5 years ago
|
||
So let's compare the two suggestions without having to open up patches.
Magnus:
credentials_incomplete=Due to authentication failure the automatic configuration process could not be completed. If the email and password you entered are correct, it is likely that you need to use a separate username for logging in. This username is usually your Windows domain login with or without the domain (e.g. johndoe or AD\johndoe).
credentials_wrong=Authentication failed. There is still a problem with the entered credentials. Please check the username and password.
Ben:
credentials_incomplete=A username is required. This is usually your Windows domain login (e.g. ACME\johndoe).
credentials_wrong=Please check the password using the eye button, and ask which format of username you need for your Exchange email account. This is usually your Windows domain login with or without the domain (e.g. johndoe or ACME\johndoe).
What needs to be done:
First message: Ask for domain user name and make sure password is correct.
Second message: Make sure both are correct.
Jörg:
Please provide a username, usually your Windows domain login in the format COMPANY\yourname. This may not be required if your password was entered incorrectly which you can verify by clicking on the eye icon.
Second:
Please verify your username and password by clicking on the eye icon.
Assignee | ||
Comment 72•5 years ago
|
||
(In reply to Jorg K (GMT+1) (PTO to 15th Dec 2019, sporadically reading bugmail) from comment #69)
AD active directory is a M$ technology that has little to do with the concept of a domain in the M$ sense
Eh, AD is exactly what the domain is in the MS sense, in this context. It's NOT the domain as in the internet domain name, it's the naming of the Active Directory domain, which can be anything.
I'm not going to spend more time on this bug now. The patch already has r, and ui-r so I'm just going to land it so we can move on with more important business.
For the wording you suggested, asking the user to click somewhere is... odd UI to say the least. The eye icon may change over time or even by changing theme used.
Comment 73•5 years ago
|
||
Maybe you want to read up on that "Active Directory" really is: https://en.wikipedia.org/wiki/Active_Directory.
In the olden days a MS domain controller existed before the advent of Active Directory, but it appears that the latter has now subsumed the former.
If you want to force your patch into the system, at least consider changing the (e.g. johndoe or AD\johndoe) stuff to this:
This username is usually your Windows domain login with or without the domain (for example: yourname or DOMAIN\yourname).
Please leave johndoe out of user-facing strings:
https://searchfox.org/comm-central/search?q=johndoe&case=false®exp=false&path=.dtd
BTW, formally your patch doesn't have an r+ but an r- from a Thunderbird peer so I can't see any legitimacy in what you announced to do.
Assignee | ||
Comment 74•5 years ago
|
||
"yourname" is not en example since nobody would ever have that as a username. John Doe on the other hand is a common English idiom.
Comment 75•5 years ago
|
||
Assignee | ||
Comment 76•5 years ago
|
||
You'd have no reason to back it out. The patch is submitted by the module owner, It has ui-review from the UX lead, and the previous iteration (adding an if-else) was previous reviewed to the extent such a two line change needs extensive review.
But sure, I can add a localization note, and change it to jane.
AD is an example and should not really be translated. Even non-English users are likely to use that.
Comment 77•5 years ago
|
||
Well, your English derailed here:
... , and the previous iteration (adding an if-else) was previous reviewed to the extent such a two line change needs extensive review.
Please point me to the attachment which according to you had positive review. The only one with r+ is the one without the strings. Are you referring to attachment 9110943 [details] [diff] [review] which has r- from you?
Assignee | ||
Comment 78•5 years ago
|
||
Alright, feel free to review the if-else then. But you already agreed in comment 56.
Comment 79•5 years ago
|
||
Assignee | ||
Comment 80•5 years ago
|
||
Fixed. r for the if-else please, per popular demand
Comment 81•5 years ago
|
||
Comment 82•5 years ago
|
||
While we're here, can we please lose the abbreviation "e.g." and use "for example":
https://searchfox.org/comm-central/search?q=for+example&case=false®exp=false&path=AccountWizard.dtd
Assignee | ||
Comment 83•5 years ago
|
||
(In reply to Alessandro Castellani (:aleca) from comment #81)
I'm sorry to propose another change, but I think we can shrink this down and
keeping the same core message.
"Authentication failed. The entered credentials might be incorrect or a
separate username might be required for logging in. This username is usually
your Windows domain login with or without the domain (e.g. janedoe or
AD\janedoe)."
Sound ok, but I'll change it slightly to have the sentence say either or instead.
Will also update to "for instance"
This is a bit of a repetition, since the authentication failed even after
typing the Login username, we can safely assume any of the typed credentials
might be incorrect.
What about:
"Authentication failed. The entered credentials might be incorrect."
Here it makes sense to specifically call out username and password since once we have the username, what the email is doesn't matter (it's not used then).
Assignee | ||
Comment 84•5 years ago
|
||
Comment 85•5 years ago
|
||
https://hg.mozilla.org/comm-central/rev/df3dbb04dd384e4c8fd7a7e01f28bde758646bb2
Follow-up - show message guiding users what to do when exchange autodiscover authentication failed. r=aleca, ui-r=aleca
DONTBUILD
Pulsebot on strike today? Anyway, thanks for the string changes.
Comment 86•5 years ago
|
||
Comment 87•5 years ago
|
||
Comment 88•5 years ago
|
||
Updated•5 years ago
|
Comment 89•5 years ago
|
||
Assignee | ||
Comment 90•5 years ago
|
||
Unfortunately I notice https://hg.mozilla.org/releases/comm-esr68/rev/02d9914009c2fbc2d9add584385d08df5127e1fc would have needed an adjustment since the id on 68 is status_area instead of status-area
I'm rebuilding locally with this to verify it works.
Assignee | ||
Comment 91•5 years ago
|
||
Updated•5 years ago
|
Assignee | ||
Comment 93•5 years ago
|
||
Rob, please land attachment 9122859 [details] [diff] [review] on comm-esr68. It's not landed elsewhere because it's a follow-up to the esr68 fix already landed earlier.
Comment 94•5 years ago
|
||
And when you do, put 68.5 in the comment and set the status-thunderbird_esr68 accordingly. That was also not done correctly in bug 1609607 and bug 1608539 and maybe elsewhere. Without that information, it will be hard to tell in which dot release things got fixed.
By the looks of it, setting status-thunderbird_esr68 was also not set on any of the bugs here and earlier :-(
https://treeherder.mozilla.org/#/jobs?repo=comm-esr68&revision=72e751b740f18dcceb4f3ed53849129929be24c7
Please talk to whoever handles releases these days.
Comment 95•5 years ago
|
||
bugherder uplift |
Thunderbird 68.5.0:
https://hg.mozilla.org/releases/comm-esr68/rev/7cdcdb0a1ea2
Updated•5 years ago
|
Description
•