Improvements to key assistant UI and strings
Categories
(MailNews Core :: Security: OpenPGP, defect)
Tracking
(thunderbird_esr91 unaffected)
| Tracking | Status | |
|---|---|---|
| thunderbird_esr91 | --- | unaffected |
People
(Reporter: mkmelin, Assigned: mkmelin)
Details
Attachments
(1 file)
The UI should show collected key sources.
In the main view, when describing the issue the key id should be shown when it's just one key.
There were structural problems in the discovery view. Also don't close it immediately, that gives an odd experience.
The key assistant css should be in messengercompose.css, not messengercompose.css
|
Assignee | |
Comment 1•2 years ago
|
||
For the key source, we should not simplify the source (attachment is not the same as autocrypt)
|
|
Assignee | |
Comment 2•2 years ago
|
||
|
||
Comment 3•2 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #0)
The UI should show collected key sources.
We already show them in the acceptance view, where are you adding them?
In the main view, when describing the issue the key id should be shown when it's just one key.
Why do you think they are needed there? The user needs to see them in the place where the user can accept them - and we already show them in that place.
There were structural problems in the discovery view. Also don't close it immediately, that gives an odd experience.
What kind of structural changes? Do you mean html bugs?
What do you instead of closing it immediately?
Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/498bcfd056bd
Improvements to key assistant UI and strings. r=kaie
|
|
Assignee | |
Comment 5•2 years ago
|
||
(In reply to Kai Engert (:KaiE:) from comment #3)
We already show them in the acceptance view, where are you adding them?
I should have been more explicit. I'm showing the actual source as a link. Instead of just saying it was from an email I link to that email and so on...
In the main view, when describing the issue the key id should be shown when it's just one key.
Why do you think they are needed there? The user needs to see them in the place where the user can accept them - and we already show them in that place.
Perhaps it's not 100% needed, but I think it's more up front to display what we have. I'd like to at some point have some control in the main view to accept all (when it's really just about the first acceptance, no other problems). That will be more work though, so not for now.
There are other cases: without any id showing, from the overview you have no idea what was found or what expired. Say you have 3 recipient keys expire, and you move back and forward in these dialogs and need to explain what the problem keys are to someone. This is harder than it should be without an id showing.
There were structural problems in the discovery view. Also don't close it immediately, that gives an odd experience.
What kind of structural changes? Do you mean html bugs?
Yes, just html structure: trying to add paragraphs inside a <p>
What do you instead of closing it immediately?
I added a wait for one second before closing. Then the did-this-button-do-anything feeling is gone at least.
|
|
Assignee | |
Comment 6•2 years ago
|
||
Sorry, noticed I have the wrong reviewer in the commit message.
Pushed by mkmelin@iki.fi: https://hg.mozilla.org/comm-central/rev/8024bba08755 follow-up - fix email source name. rs=me DONTBUILD
Pushed by mkmelin@iki.fi: https://hg.mozilla.org/comm-central/rev/c17365dc7e4e follow-up - Add a localization comment. rs=me
Description
•