[autoconfig] Make domain bold

RESOLVED FIXED in Thunderbird 66.0


8 months ago
6 months ago


(Reporter: BenB, Assigned: BenB)


Thunderbird 66.0
Dependency tree / graph

Thunderbird Tracking Flags

(thunderbird65 fixed, thunderbird66 fixed)



(2 attachments)

In the account creation dialog, when we found a config, we display the result config in a concise way.

To allow the user to more easily make secure decisions, we should make the second level domain of the hostname bold. E.g. for imap.mail.yahoo.com, we should make "yahoo.com" bold.

This is the trust anchor, and in fact more important than SSL: An attacker can easily set up SSL on his own domain, but he can't easily get the correct domain.
To allow the user to more easily make secure decisions, we should make the second level domain of the hostname bold. E.g. for imap.mail.yahoo.com, we should make "yahoo.com" bold.
Attachment #9029122 - Flags: review?(acelists)
Comment on attachment 9029122 [details]
[autoconfig] Make domain bold

aceman r+ on Phab
Attachment #9029122 - Flags: review?(acelists) → review+
Keywords: checkin-needed
Target Milestone: Thunderbird 60.0 → Thunderbird 66.0
Version: 60 → Trunk
Pushed by mozilla@jorgk.com:
[autoconfig] Make domain bold. r=aceman DONTBUILD
Closed: 7 months ago
Keywords: checkin-needed
Resolution: --- → FIXED
Pushed by geoff@darktrojan.net:
[autoconfig] Make domain bold - Fix typo in CSS. r=jorgk
I did point out the typo on Phabricator :)
Well, that Phabricator is so totally well integrated (not!) that mistakes like this a bound to happen. The patch was first landed in the wrong bug since I had to copy together a HG header and I got the bug number wrong by mistake.

Curiously "hg phabread" usually produces a complete header, but not in for Ben & Co where the header is missing the author and the bug number. BTW, Lando refuses to land them with:
  Diff does not have proper author information in Phabricator. See the Lando FAQ for help with this error.

Fun fact: "hg phabread" produced a patch encoded in windows-1252/ISO-8859-1, so ellipses went up the creek, and had it not been for a merge/apply error, I wouldn't have noticed that either.

Quoting from the chat:
23:37:09 - BenB: mozilla braucht so ein riesen-geschrotter an tools, die mich alle haare verlieren lassen.
23:37:58 - BenB: ich sage nur: ich habe heute ein paar stunden verloren bei den versuch, das alles aufzusetzen.
confirms that the whole Phab stuff is a giant productivity destroyer, at least so far.

The positive side is that I can now land M-C patches without having to have an m-i repository locally.
BTW, the Windows instructions are just a joke: https://moz-conduit.readthedocs.io/en/latest/arcanist-windows.html
"Only" 12 steps to set it up. Compare that to "hg qnew -m "Bug NNN - fixed yah di yah. r=aceman" NNN-fixed-yah-di-yah.patch" and upload; there was even a HG tool to upload patches automatically.

And "hg qimport" has never re-encoded patches in a different charset so far for me.
Attachment #9029122 - Flags: approval-comm-beta+
Attachment #9029122 - Flags: approval-comm-esr60?
Attachment #9029122 - Flags: approval-comm-esr60?

Please do not put this in TB 60 in its current form. It uses new strings and makes everything fail. I might update it. But this fix is just optics and is not required for Exchange or Owl, so we could skip this for TB 60.

Your call. BTW the patch does not have new strings, you only remove some.

True. However, it uses a new string that bug 1500105 trunk patch added. The TB 60 patch for bug 1500105 doesn't have that new string and thus the patch here fails.
I could make a new, TB 60 specific patch. But given that this bug is only an optical improvement, and I'd rather push this out to TB 60.6 or skip it entirely.

You need to log in before you can comment on or make changes to this bug.