Regression seen on 98.0a1 (2022-01-25) (64-bit), Win10

New AB has lost all high efficiency keyboard shortcuts to edit the selected contact (default action), especially plain Enter.
Even double-click no longer triggers the default action (edit contact).
This is an annoying usability regression, more so for the blind.

• Double-click on a contact for default action (edit contact).
• Enter (all OS) for default action of selected item (edit contact).
• Alt+Enter (Windows/Linux) and Ctrl/Cmd+I (all OS) - per-OS default shortcuts to edit the properties of a selected item.

Editing contacts now requires much more effort and attention:

• mouse: less convenient, needless mouse click on distant Edit button
• keyboard: (4x or 5x) Tab, Enter. Note: 5x Tab is required when reduced window width causes horizontal scroll bar on contact pane.

Worse, Ctrl/Cmd+I unexpectedly triggers New Calendar Event, which looks like a pretty unlikely workflow.

STR:

1. Open ("new") Address Book
2. Click to select contact A
3. Press keyboard shortcuts to edit the selected contact:

• Enter or double-click (all OS)
• Alt+Enter (Windows/Linux) or
• Ctrl/Cmd+I (all OS)

Actual results:

• nothing for Enter or double-click on a contact (all OS)
• nothing for Alt+Enter (Windows/Linux)
• Ctrl/Cmd+I (all OS) triggers New Event dialog

Expected results:

• Restore plain vanilla Enter shortcut for the selected item default action, edit contact.
• Restore plain vanilla double-click to edit contact.
• Restore convenience shortcuts for consistency with OS default shortcuts on the respective OS to edit the properties of an item (which imo prohibits using Alt+Enter and Ctrl/Cmd+I for anything else here even if we wanted). That said, we may want to reflect a bit more on the new conflict with Ctrl/Cmd+I for creating a new calendar event, so OK to delay restoring Ctrl/Cmd+I.

We should really try to fix this before shipping, annoying for everyone, very bad for the blind. Fixing this would also simplify manual testing quite a lot.

This screenshot illustrates the unnecessary navigation caused by this bug (vertical layout):

• Mouse users: Instead of just double-clicking on a contact, they have to navigate a long way to the edit button (see screenshot)
• Keyboard users: Instead of just pressing Enter on a selected contact, they have to press 4x Tab first to focus the edit button

This screenshot illustrates the unnecessary navigation caused by this bug (horizontal layout):

• Mouse users: Instead of just double-clicking on a contact, they have to navigate a long way to the edit button (see screenshot)
• Keyboard users: Instead of just pressing Enter on a selected contact, they have to press 4x Tab first to focus the edit button

Comment on attachment 9277989 [details]
Screenshot 2 (horizontal layout): Unnecessary mouse navigation caused by this bug (no double-click nor Enter to edit a selected contact)

.

Comment on attachment 9277980 [details]
Screenshot 1 (vertical layout): Unnecessary mouse navigation caused by this bug (no double-click nor Enter to edit selected contact)

.

@thomas8 I think we'll have to think about this. Pressing Enter on an item, or double clicking an item, is understood as "activating" the item. But I'm not sure "activating" a contact item would necessarily be understood as editing it because a contact has a lot of non-editing functionality. I think "show contact details" would be more obvious, but we already show them on changing selection.

Moreover, the old addressbook "edit" took place in a new window, but the layout is different now with both the view and the edit functionality in the side pane. Therefore, accidentally triggering an edit is more disruptive now.

However, a quick means to edit a contact could be made available via the context menu, which would seem to address your issue of moving the mouse a long way.

(In reply to Henry Wilkes [:henry] from comment #6)

@thomas8 I think we'll have to think about this. Pressing Enter on an item, or double clicking an item, is understood as "activating" the item.

Yes. More precisely, Enter or double-click performs the default action associated with an item (often open).

I think we can agree that the main purpose of an address book is managing contacts, so the most typical one-fits-all default action here should remain Edit (as you say, View already happens on selection).

But I'm not sure "activating" a contact item would necessarily be understood as editing it because a contact has a lot of non-editing functionality. I think "show contact details" would be more obvious, but we already show them on changing selection.

Exactly. The other actions Write, Event, Search are certainly useful, but not suitable as a default here:

• Write: No need to promote and give high-value access to Write from AB because it probably makes more sense to just use recipient autocomplete or Contacts Sidebar for that (which has an incompletely realized default action of Write, because it lives in a composition context, where writing would appear the most likely action).
• Event: Certainly very useful, but is it for everyone and could it be the default action for a contact in an address book?
• Search: dito

Iow, those are more like additional actions which we offer for convenience (and we could certainly consider giving them dedicated shortcuts).

Moreover, the old addressbook "edit" took place in a new window, but the layout is different now with both the view and the edit functionality in the side pane. Therefore, accidentally triggering an edit is more disruptive now.

Well, accidental double-clicks will always be disruptive in some way - that's not an argument against the double-click. Accidental Enter is unlikely. The "disruption" would be very low now (much less disruptive than a whole dialog popping up), just press Esc and you're back to where you came from (if we fix Bug 1769957 to place focus back on the selected contact, which probably makes sense for consistency with Save, and if we implement this bug, editing a selected item becomes a snap).

However, a quick means to edit a contact could be made available via the context menu, which would seem to address your issue of moving the mouse a long way.

The context menu is needed, but it cannot replace or compete with the ultimate convenience and efficiency of just pressing Enter or double-clicking on a contact to edit it.

In theory, we could offer a pref and let the user choose his favorite default action, but imo that would be over-engineering, and I'd still argue that any default action other than Edit would be a very strange choice for an address book.

I promise that many users (with enterprise users at the forefront) will scream pretty loud about this regression as soon as they get aware of it. Breaking long-standing use patterns is another aspect to consider.

That said, let's hear what others think.

(In reply to Thomas D. (:thomas8) from comment #7)

I think we can agree that the main purpose of an address book is managing contacts, so the most typical one-fits-all default action here should remain Edit (as you say, View already happens on selection).

I'm not sure we can be so confident about this. I would expect the new addressbook would be primarily for reading contact details and contacting (sending an email, or chatting, etc). I would expect editing an existing contact to be less frequent because you have already given initial data when you created the contact, and any other changes would be made with the expectation that it would be read or used once or more. So, overall, I don't think "edit an existing contact" could be universally considered a default or most-frequent action, or even secondary to "view contact" since we also have "email contact", "message contact", etc.

let the user choose his favorite default action

Small note, could you please use singular "they" to refer to a user since they might not be a man :)

[...] I'd still argue that any default action other than Edit would be a very strange choice for an address book.

I do believe that the default action for a "click"(or main action) should be to establish a reading from the beginning to the end of the contact view with a screenreader.

As a middle ground we might shift the tab order to let the edit be one tab away?

(A little bit more elaboration: I think the wide spread material UI approach on smartphones let us think that the most important action is always "right" although for accessibility tree parsing screen readers it should be "left". I kinda believe that this gives us a reason to shift the tab ordering from the visual representation)

Considering the multi selection of contacts (See app presentator) i do think that a click/enter on a contact to open the contact in edit view could be confusing and be in the way of doing said action.
I do believe here too that in the multi selection mode with the main action pressed on a selected item a reading should be triggered of the view.

(In reply to Nicolai Kasper from comment #9)

[...] I'd still argue that any default action other than Edit would be a very strange choice for an address book.

I do believe that the default action for a "click"(or main action) should be to establish a reading from the beginning to the end of the contact view with a screenreader.
[...]
Considering the multi selection of contacts (See app presentator) [...] I do believe here too that in the multi selection mode with the main action pressed on a selected item a reading should be triggered of the view.

I think there is some confusion here. This area is essentially a table (grid) where each row is a contact. Eventually, the "Space" key will be used to select a row/contact. By default, navigating the focus will also select a single row (I'm working on this in bug 1752532). Selecting a contact is what controls the display in the side pane.

For such an element there is no requirement to respond to "Enter". It is an exception for it to have an effect. But in practice, it often "open"s the corresponding row. E.g. in the message tree grid, pressing "Enter" will open the message in a new tab, or in the attachment list it will open the attachment. However, in our case we already "open" the row on selection, so we have no need to do this on "Enter".

A full read of the contact view is generally not useful, and it can be triggered when using a screen reader if needed. This is generally outside our control, and it is good that this is the case because a user knows best what they want.

As a middle ground we might shift the tab order to let the edit be one tab away?

I don't think hacking the tab ordering is a good idea. The order in which a visual user would read the page should be the same as the DOM ordering, otherwise we would be splitting the user experience. If we think "Edit" should be first, then that can be reflected in the visual display as well, but I don't think there is any plan to do this.

As a middle ground we might shift the tab order to let the edit be one tab away?

Never, ever, ever do that :D
We did it in the past and it's sketchy.

I'm okay with adding an "Edit" entry to the context menu, but double click or Enter/Alt+Enter is a no go for me.
I agree with the extremely detailed and valid explanation Henry brought up.

@all: This bug is a regression, not an RFE.

Dear friends of Thunderbird, I think it's worth noting that this bug is not a feature request, it's a regression.
I cannot believe that we're having this discussion, but let's have it since ideas of ux-efficiency seem to vary widely.

Double-click/Enter to trigger the default action of a list item (up to TB 91: Edit contact)

For decades, Thunderbird users have been able to edit their contacts by a simple double-click on the contact (regardless of its selection state) or by pressing Enter on a selected contact, to trigger the contact's default action, Edit contact. We should not rush to remove such basic ux-efficiency workflows, which has a high risk of backfiring - please have a look at bug 1685007 (currently at comment 115) to understand the fireworks of user frustration and anger when forcing users into extra clicks which could be avoided one way or the other. Imho, this bug falls into the same category.

Alt+Enter/Ctrl/Cmd+I: OS default shortcuts for item properties (up to TB 91: Edit contact)

Similarly, Thunderbird currently supports the following universal OS default shortcuts on a single selected contact for the more technical, traditional notion of item properties (because whenever editing a contact, you'll actually edit its properties):

• Alt+Enter on Windows/Linux (on Windows, this will open the properties of virtually any item, try it in Explorer)
• Cmd+I on Mac (this is the official Mac shortcut for item properties)
• Ctrl+I on all OS for cross-OS consistency and easier support (this is courtesy of Thunderbird)

I don't think we could or should ever use these shortcuts for anything else on a single selected contact, because that would violate ux-consistency with the OS platforms, which may be unexpected for users. Ctrl/Cmd+I is a bit tricky as in the main window, we're using that for New Event. I would be ok with postponing Ctrl/Cmd+I pending further exploration. Also, restoring these shortcuts is pretty independent of the default action issue.

Default action on items in lists: The ux-efficiency booster in Thunderbird and elsewhere (via Double-click/Enter)

The whole point of pre-defining a default action from many possible actions on a given item from a list is to boost ux-efficiency. Imagine if you had to go through Context menu > Open every time you open a file from your OS file manager - that would suck, right? Indeed. Same here.
It is universally accepted practice that the default item action will be triggered by a double-click on an item (regardless if it was selected before or not, so you can directly double-click on an item without prior selection). The keyboard equivalent is pressing Enter on a selected item. So for many lists of items, single-click selects, and double-click (or Enter) triggers default action. Which is extremely efficient, and we all benefit from this every day.

As Henry has correctly pointed out, Thunderbird makes extensive use of the default action concept:

• double-click on a message from message list triggers Open message [for editing] default action (and you can finetune how it should be opened)
• double-click on an attachment from attachments list typically triggers Open attachment default action (and you can tweak and change that in several ways)
• double-click on a filter from filter list triggers Open/Edit filter default action
• double-click on a contact from contacts list triggers Open/Edit contact default action. All versions of TB up to and including TB 91.

Same for Enter on any such single item when selected.
All of these are part of the ux-efficiency design which makes users love and prefer Thunderbird over webmail.

Thunderbird 102 introduces new actions for AB contacts - why should Edit contact remain the default action for Double-click/Enter?

That's a fair question. I've explored this already in my Bug 1752013 Comment 7. Let's go through the possible actions one by one and see if they are suitable default actions (under the premise that we're not offering the user to choose the default action). It's worth noting that default actions are not only about usage frequency. Different users have different needs, so absolute frequency of actions may vary and is hard to predict. Maybe you only ever use your file manager to delete or rename files, but would you ever want deleting or renaming as your default action on files? Double-click to delete? Double-click to rename? Moreover, would you find it acceptable if your OS would choose deleting or renaming as a default action for files? We have a somewhat similar situation here. It's not just about absolute frequency, it's also about universal acceptance. Default actions should be safe and work reasonably well (without much surprise) for all types of users.

Note 1: Triggering default action via Double-click/Enter must be limited to a single (selected) contact

• Double-click on multiple selected items will typically deselect all items except the one you double-clicked on.
• Enter on multiple selected items should be disabled (sometimes works, e.g. on multiple selected files in Windows Explorer)

Note 2: After a selecting a contact (with single left click or navigation keys), the inherent default action is View contact. Fixing this regression will not change that!

• Write: At first sight this may look like a good default action, and certainly possible if we'd allow the user to choose the default action. Otoh, do we really want to promote to start writing messages from AB? My take: No need to promote and give high-efficiency access to Write from AB because it probably makes more sense to just use recipient autocomplete or Contacts Sidebar for that (which has an incompletely realized default action of Write, because it lives in a composition context, where writing would appear the most likely action). Why Write and not Chat? Last but not least, this could be easily realized through Ctrl+M (bug 1752028).
• Chat: Not possible as a default, as many users may not even have this set up. Why Chat and not Write?
• Event: Certainly very useful, but will this be a safe and useful default for all kinds of users? What if they don't have a calendar set up or they are not using it for invites? Why not Write?
• Search: Certainly very useful, but will this be a useful default for all kinds of users?
• Edit: Given that Open for viewing is covered by selecting the item(s), this is a safe default for all kinds of users from Grandma to power user. No surprises. Double-click a contact in your address book, and it will open for editing. Everyone can understand that, no one can blame us. This is how things have worked since Thunderbird 1.0, and it's a known concept inside and outside Thunderbird (like you open any other data file for editing). Nobody has ever requested to change the default. All users (including enterprise!) who need to edit contacts more than once in a while will love the efficiency. Remove this, and they will hate us. Editing contacts may also happen pretty frequently e.g. for contacts automatically collected from sending.

Way forward

• I strongly believe that removing an every day ux-efficiency feature which has existed forever in Thunderbird should require utmost caution and consideration, and there would have to be strong arguments in favor of removing it, more so given that nobody ever complained.

• While Henry has raised some doubts on this, I'm not seeing that he has already positioned himself explicitly against fixing this regression. Let's not misread some of Henry's statements like this one:

  However, in our case we already "open" the row on selection, so we have no need to do this on "Enter".

  Iiuc, this statement is not against restoring Edit contact as a default action, but simply says that there's no need to make Open for *viewing* the default action (via double-click/Enter) because we already do that automatically when the user selects a contact (via single-click/keyboard navigation). Which in turn would allow us to keep Open for editing aka Edit contact as a default action, exactly as in TB 91.

• Iiuc, what Henry and Alex have said so far boils down to not having any default action at all, i.e. make double-click and Enter on a contact do nothing. As usual (and it's not the first time I'm having such discussions), I'm failing to see how doing nothing on well-known shortcuts can be better than doing something useful, for those users who know these universal usage patterns and want to benefit from them.

• Fixing this regression will not have any disadvantages for anyone else. In almost 20 years, nobody has ever complained the status quo. This is not a case of ux-error-prevention (for details, see my comment 7); if it were, please write to Microsoft and ask them to remove double-click to open files, and make sure you can handle the shit storm that would follow if they did. In fact, iirc, they once tried opening files on single-click in an attempt to ride on the browser hype, but looks like that feature has come and gone fast because nobody wanted that.

• If we really believe that users will have strong feelings about making one of the new actions their personal default action, fixing this regression will not stop us from implementing a pref allowing users to choose their favorite default action in the future (definitely too much work for now).

Yes, but...

Feel free to disagree with decades of universal ux-efficiency in Thunderbird. If you do, kindly answer all of the following questions:

1. Why has Thunderbird implemented a default action for other important lists like the message list? Would you advocate for removing those default actions as well?
2. What are your specific arguments in favor of removing this long-standing ux-efficiency feature (especially removing Edit contact as a default action, but also removing Alt+Enter shortcut for the majority of Windows users)? More so given that nobody ever complained or asked to change it?
3. What's your answer to enterprise users who may need to edit dozens of contacts every day, and who have reported to us on countless bugs that every click counts and ux-efficiency matters?
4. If you're proposing to have no default action at all on contacts: How is doing nothing on well-known shortcuts (double-click/Enter) better than doing something useful, for those users who know these universal usage patterns and want to benefit from them?

I rest my case. Sorry for wall of text, but tbh I find this outrageous and I'm shocked how some of us are willing to break long-standing basic ux-efficiency so casually, whereas ux-efficiency is part of the brand core of Thunderbird.

Btw, as a personal sidenote, this regression is driving me mad every time that I have to edit contacts for testing purposes, which is pretty frequent. I guess enterprise users who just want to get their work done will feel the same.

Please, don't pollute the title to reiterate the point.
You wrote a pretty detailed and on point STR and overview of the issue, no need to create massively long bug titles.

(In reply to Thomas D. (:thomas8) from comment #7)

(In reply to Henry Wilkes [:henry] from comment #6)

@thomas8 I think we'll have to think about this. Pressing Enter on an item, or double clicking an item, is understood as "activating" the item.

Yes. More precisely, Enter or double-click performs the default action associated with an item (often open).

I think we can agree that the main purpose of an address book is managing contacts, so the most typical one-fits-all default action here should remain Edit (as you say, View already happens on selection).

But I'm not sure "activating" a contact item would necessarily be understood as editing it because a contact has a lot of non-editing functionality. I think "show contact details" would be more obvious, but we already show them on changing selection.

Exactly. The other actions Write, Event, Search are certainly useful, but not suitable as a default here:

• Write: No need to promote and give high-value access to Write from AB because it probably makes more sense to just use recipient autocomplete or Contacts Sidebar for that (which has an incompletely realized default action of Write, because it lives in a composition context, where writing would appear the most likely action).
• Event: Certainly very useful, but is it for everyone and could it be the default action for a contact in an address book?
• Search: dito

Iow, those are more like additional actions which we offer for convenience (and we could certainly consider giving them dedicated shortcuts).

Moreover, the old addressbook "edit" took place in a new window, but the layout is different now with both the view and the edit functionality in the side pane. Therefore, accidentally triggering an edit is more disruptive now.

Well, accidental double-clicks will always be disruptive in some way - that's not an argument against the double-click. Accidental Enter is unlikely.

Whether or not it (accidental double-clicks) is unlikely or not is I think besides the point.
a) this is reversing long standing behavior that results in efficiency for the user
b) if such accidental activity occurs 1) it is easily reversed by escape key 2) you would hope accidental triggering will eventually train the user to avoid the triggering behavior

However, a quick means to edit a contact could be made available via the context menu, which would seem to address your issue of moving the mouse a long way.

The context menu is needed, but it cannot replace or compete with the ultimate convenience and efficiency of just pressing Enter or double-clicking on a contact to edit it.

I agree, per above

In theory, we could offer a pref and let the user choose his favorite default action, but imo that would be over-engineering, and I'd still argue that any default action other than Edit would be a very strange choice for an address book.

yes, that would be over engineering - prefs are to be avoided.

This is effectively a regression of UI. And while I'm not against changing UI behavior to advance the greater good, I don't see the greater good here.

And in fact, on further reflection, I think it is very bad

(In reply to Wayne Mery (:wsmwk) from comment #16)

And in fact, on further reflection, I think it is very bad

+1. Simply put, this will drive users nuts. -> S2.

Adrien, Richard, how are you seeing this regression from an enterprise user pov wrt ux-efficiency?

• Double-click on a contact in address book will now do nothing instead of editing it (which used to be the default action in TB 91).
• Enter on a selected contact in address book will also now do nothing instead of editing it.
• Alt+Enter (on Windows), Cmd+I (on Mac) or Ctrl+I are also no longer available as system default shortcuts for Edit item properties which translates to Edit contact in TB 91

Consequently,

• Mouse users either have to navigate to distant Edit button (see screenshots in comment 2 and comment 3), or to right-click on contact > navigate > Edit
• Keyboard users currently need at least 4 keypresses to get from a selected contact into editing mode (context menu key > arrow-down > arrow-down > Enter), or 4x Tab.

Thunderbird has had Edit Contact as a default action (via double-click/Enter) for AB contacts in the AB window since time immemorial. Has this been a problem for your enterprise environments in the past?

Apart from Edit Contact, we are offering some existing and some new actions for contacts, on the new toolbar for contacts (see screenshots)

• Write
• Event (invites the selected contact)
• Search (global search for all communication involving the contact)
• Chat (not yet implemented)

In your enterprise environments, would you think any one of these would make a better default action in the address book than Edit Contact?
(If yes, do you think Thunderbird could make that action the default for all types of users including private users, who may not use calendar or chat?) Note: As in TB 91, selecting a contact will display the contact. Selecting a contact to write to is also possible in composition's recipient autocomplete or Contacts Sidebar (F9 in composition).

(In reply to Thomas D. (:thomas8) from comment #18)

Adrien, Richard, how are you seeing this regression from an enterprise user pov wrt ux-efficiency?

• Double-click on a contact in address book will now do nothing instead of editing it (which used to be the default action in TB 91).
• Enter on a selected contact in address book will also now do nothing instead of editing it.
• Alt+Enter (on Windows), Cmd+I (on Mac) or Ctrl+I are also no longer available as system default shortcuts for Edit item properties which translates to Edit contact in TB 91

Consequently,

• Mouse users either have to navigate to distant Edit button (see screenshots in comment 2 and comment 3), or to right-click on contact > navigate > Edit
• Keyboard users currently need at least 4 keypresses to get from a selected contact into editing mode (context menu key > arrow-down > arrow-down > Enter), or 4x Tab.

Thunderbird has had Edit Contact as a default action (via double-click/Enter) for AB contacts in the AB window since time immemorial. Has this been a problem for your enterprise environments in the past?

Hi Thomas,

Thanks for the question.

I agree with what you said in comment 7 and 12.

Users are familiar with contact editing in action by default.
Even if the new actions are nice, an address book is still primarily a place to add/edit contacts.

Apart from Edit Contact, we are offering some existing and some new actions for contacts, on the new toolbar for contacts (see screenshots)

• Write
• Event (invites the selected contact)
• Search (global search for all communication involving the contact)
• Chat (not yet implemented)

In your enterprise environments, would you think any one of these would make a better default action in the address book than Edit Contact?
(If yes, do you think Thunderbird could make that action the default for all types of users including private users, who may not use calendar or chat?) Note: As in TB 91, selecting a contact will display the contact. Selecting a contact to write to is also possible in composition's recipient autocomplete or Contacts Sidebar (F9 in composition).

The other features are a good addition and can be used as shortcuts, but are not really standards.

Write, if the contact has several email addresses it is better to click among the list proposed on the display of the contact information, because in action by default it will send it to the main email and it is not necessarily what we can wish.
The presentation of the different addresses with the mailto incorporated is sufficient, no need to make it a default action.

For events, it is as fast to create an event, add the user as to go through the address book if you are not directly on the contact.
The search is really nice but when you go to the address book it is not to have by default, the search for communications with a contact.
The chat remains quite specific, not all users will use it.

Edit contact should remain the default action.

I'll take this and put a patch together.

Out of curiosity, to wayne and thomas: have you been using the "Edit" option in the context menu since it landed? Has that helped alleviate your problems?

I use context menu when necessary, but as a keyboard centric person I use keyboard shortcuts and double clicks where possible. So based on habit I have not been using edit on the address book context menu - mostly been using the edit button on the contact pane. (but I haven't been doing much editing in recent months, so I may be a poor choice for giving feedback about context menu)

p.s. I'm sure I have also used <enter> to invoke edit, probably when using arrow keys (rather than mouse) to go through contacts.

(In reply to Henry Wilkes [:henry] from comment #20)

I'll take this and put a patch together.

That's awesome, thank you for being the hero who restores ux-efficiency of editing contacts, avoiding needless floods of bad feedback from users as we've seen it in similar ux-efficiency Bug 1685007.

Out of curiosity, to wayne and thomas: have you been using the "Edit" option in the context menu since it landed? Has that helped alleviate your problems?

Having the Edit action in context menu is mostly a logical necessity - skipping the default action in the list of actions would be weird. It's also good for exploration and discovery. In fact, it's good practice to show the default action at the very top of the context menu, even in bold (cf. Windows explorer file context) - can we do that please?

For mouse users, contextual Edit may be somewhat better than status quo e.g. for contacts far down the list, as it avoids navigating to the distant Edit button on top. However, contextual Edit is still way too clumsy and error-prone for regular usage: Nothing beats the no-brainer simplicity and efficiency of just double-clicking to edit.

(In reply to Wayne Mery (:wsmwk) from comment #22)

p.s. I'm sure I have also used <enter> to invoke edit, probably when using arrow keys (rather than mouse) to go through contacts.

Enter on selected item is the keyboard equivalent for double-click item, both are required to restore the default action status of Edit.
Without Enter, the keyboard-only workflow (e.g. for the blind) would remain pretty cumbersome: who wants 4 or 5 different keypresses which needs a lot of attention when the item is already selected and a simple Enter can do?

Restoring Enter forms part of the minimal acceptance criteria for this bug, and I'm confident that Henry will be able to fix that, too.

Actually, I'll do another try run to be sure

Pushed by nicolai@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/146e970f6797
Double click or Enter on a contact item edits the contact. r=aleca

Yay!!! Verified fixed on 104.0a1 (2022-07-02) (64-bit), Win10. Please uplift to esr102 asap.

Apart from ux-efficiency of editing contacts restored, I also like the improved focus behaviour.

Comment on attachment 9282801 [details]
Bug 1752013 - Double click or Enter on a contact item edits the contact. r=aleca

[Approval Request Comment]
Regression caused by (bug #): unknown
User impact if declined: restores previously available keyboard shortcuts
Testing completed (on c-c, etc.): verified on daily
Risk to taking this patch (and alternatives if risky):

Comment on attachment 9282801 [details]
Bug 1752013 - Double click or Enter on a contact item edits the contact. r=aleca

[Triage Comment]
Approved for beta

Thomas can you test this when the beta is tested or shipped?

Thunderbird 103.0b3:
https://hg.mozilla.org/releases/comm-beta/rev/5c6f1eca0fd5

Should bug 1777505 also be uplifted to beta since the intermittent was caused by this patch? I'm not sure when it comes to fixes like that.

Yes, please request uplift to beta and reference this bug.

Comment on attachment 9282801 [details]
Bug 1752013 - Double click or Enter on a contact item edits the contact. r=aleca

[Triage Comment]
Approved for esr102

Thunderbird 102.0.2:
https://hg.mozilla.org/releases/comm-esr102/rev/a65ba628e6cf

(In reply to Wayne Mery (:wsmwk) from comment #29)

Comment on attachment 9282801 [details]
Thomas can you test this when the beta is tested or shipped?

Had already tested this and verified fixed in comment 27 (for Daily).
Verified fixed also for 103.0b4 (64-bit) and 102.0.2 (64-bit), Win10.