[autoconfig] Make domain bold

RESOLVED FIXED in Thunderbird 66.0

Status

enhancement
RESOLVED FIXED
6 months ago
4 months ago

People

(Reporter: BenB, Assigned: BenB)

Tracking

Trunk
Thunderbird 66.0
Dependency tree / graph

Thunderbird Tracking Flags

(thunderbird65 fixed, thunderbird66 fixed)

Details

Attachments

(2 attachments)

Assignee

Description

6 months ago
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.
Assignee

Comment 1

6 months ago
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.
Assignee

Updated

6 months ago
Attachment #9029122 - Flags: review?(acelists)
Assignee

Comment 2

5 months ago
Comment on attachment 9029122 [details]
[autoconfig] Make domain bold

aceman r+ on Phab
Attachment #9029122 - Flags: review?(acelists) → review+
Assignee

Updated

5 months ago
Keywords: checkin-needed
Target Milestone: Thunderbird 60.0 → Thunderbird 66.0
Version: 60 → Trunk

Comment 3

5 months ago
Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/f6a51d60470f
[autoconfig] Make domain bold. r=aceman DONTBUILD
Status: ASSIGNED → RESOLVED
Last Resolved: 5 months ago
Keywords: checkin-needed
Resolution: --- → FIXED

Comment 5

5 months ago
Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/9f896c82471d
[autoconfig] Make domain bold - Fix typo in CSS. r=jorgk

Comment 6

5 months ago
I did point out the typo on Phabricator :)

Comment 7

5 months ago
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.

Comment 8

5 months ago
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.

Updated

5 months ago
Attachment #9029122 - Flags: approval-comm-beta+

Updated

5 months ago
Attachment #9029122 - Flags: approval-comm-esr60?
Assignee

Updated

4 months ago
Attachment #9029122 - Flags: approval-comm-esr60?
Assignee

Comment 12

4 months ago

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.

Comment 13

4 months ago

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

Assignee

Comment 14

4 months ago

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.