yes, and as you can see from the CL description, this was a conscious choice.

Oh sorry, I missed that bit.

What's the motivation for this?

To make bubbles more consistent and predictable (usually, dismissal via escape is distinct from the negative action). You can follow up with Hwi and Alex if you have strong opinions and ideas for improvement.

Are there other bubbles where an effect happens on opening them?

I'll follow up with the ux folks, thanks.

Is there a way to trigger removal from the keyboard? I use esc to bail out of accidental cmd+Ds, too.

tab tab space

:/

estade@: on Mac, that only works with full keyboard access turned on system-wide… otherwise tab is a noop in that bubble.

I'll admit I'm not a mac user but that seems strange. Does that mean there's no way to change the folder with the keyboard? Seems like a lot of basic actions would be impossible without the keyboard if tab is a no-op.

estade@: Correct. I'll admit that, when you describe it like that, it sounds strange :). It feels natural to me on Mac, though.

Some controls in Mac apps *can* get keyboard focus and participate in a tab cycle (e.g. text fields, the filesystem browser in an open/save dialog). Modals usually have dedicated keyboard shortcuts for buttons. e.g.

- esc and cmd+. both mean "never mind".
- return means "do the thing".
- cmd+backspace means "don't save changes" when closing a file.
- cmd+d means "go to the desktop" in a filesystem browser.

For buttons without keyboard shortcuts and controls like popup menus, yep, you just use the mouse ("full keyboard access" is available as a system setting for keyboard-only folks).

Alt+R works for me to trigger the remove button.

Not on Mac (and it would be a pretty unusual if it did…).

FWIW, when I turn on MacViews, cmd+. also dismisses the bubble, but keeps the bookmark, which is extra weird: not all dialogs respond to cmd+. (I think), but, when they do, it should be the negative action (and generally the same action as esc).

Re: c#8:

> I'll admit I'm not a mac user but that seems strange. Does that mean there's no way to change the folder with the keyboard? Seems like a lot of basic actions would be impossible without the keyboard if tab is a no-op.

Full keyboard navigation is optional on the Mac. You have to change a setting to enable it.

On the Mac, Escape is the keyboard shortcut for the Cancel button. The bookmarks dialog's Remove button is Cancel, so pressing Escape on the Mac should continue to work as it has. The motivation behind the cl cited in the bug description came before the Harmony effort to rethink secondary UI interaction - the decision needs to be revisited, and worked into the overall Harmony guidelines.

It appears that this issue all started with estade@'s work in  Issue 585312 . It looks like he consolidated code, and in c#6 his work led to a change to the behavior of the Escape key in bubbles. This appears to be a decision made solely by him, without input from UX.

That behavioral change resulted in  Issue 609079 , which is the change that broke Escape in the Bookmarks dialog. c#3 of this bug suggests that this was driven by UX's desire to address a consistency issue, but in actuality it was a patch for a regression caused by  Issue 585312 . 

As the original change was not approved by UX I am marking this bug as a regression (but I want to discuss briefly with bettes@ before proceeding).

No, this was discussed with ux. I have a thread with ux somewhere, I can forward it to you.

c#6 in estade@'s original bug suggests that his work there was neither driven by nor approved by UX:

"So this patch creates a behavioral change: pressing escape or otherwise closing the window does the same thing as pressing "Wait", which I believe is desirable."

It might suggest that, but then that's suggestion is wrong :-) hwi@ and ainslie@ were ux folks for this.

Of course I may be wrong, but I am not convinced that is the case. It looks like  Issue 585312  was filed because estade@ wanted to consolidate classes. The original behavioral change appears to be collateral damage. It looks like UX was brought in later to advise on dealing with the aftereffects of his original change.

Stepping back a bit, it makes sense to me that esc is a "bail out" key which should map to the user's concept of "don't do anything".  For some dialogs that are asking for confirmation of user action, this is clearly "cancel", and maybe the button label is even "cancel".

In other cases our buttons don't map neatly to the concept of "cancel".  In the case of the bookmarks bubble, for example, ctrl-D is not popping up a confirmation dialog on bookmarking.  Rather, the bookmarking has already occurred, and we are popping up a convenience dialog that has buttons that both result in making some subsequent change.  "Remove" is not the same as "Cancel" in this case; it's more like an "Undo".

There are similar issues in other places (auto signin, manage passwords) where we don't have a button named "cancel" and the buttons at the bottom all take some significant action.  In these cases, mapping esc to any of the buttons is problematic, because there's a significant difference between "make the dialog go away, don't do anything" and any of the actual buttons at the bottom.

In Harmony, my understanding is that we're dealing with this as follows:

* Split dialogs into two classes, one where we have to have an answer, and one where it's safe to just dismiss the dialog while taking no action.
* For the first class, have no close button.  The buttons at the bottom are your choices.  For the second class, have a close button, and eliminate any sort of "cancel" at the bottom that's redundant with that close button.
* For the first class, sometimes esc wouldn't be mappable, but maybe sometimes it could map to one of the buttons if it's equivalent to "don't do anything".  For the second class, esc always maps to the close button.

Given this plan and the preceding rationale, I think the changes here make sense and we shouldn't revert this behavior.  I think that will be uncomfortable for people whose mental model was "hitting ctrl-d pulls up a confirmation dialog".  If we want to change how esc functions after hitting ctrl-d to be a "don't bookmark", then I think we'd need to argue for a flow where that mental model is correct: ctrl-D doesn't actually bookmark anything, it pulls up an "Add bookmark" dialog with a close box to not add the bookmark, and an "add" button to actually add it.  I don't think that would be a good change to make, but it's certainly something that could be argued.

+CC hwi, the interaction designer on Harmony who pointed me at this bug; Hwi and I are also going to chat more in person about the larger issue here to make sure we both understand it, since as I mentioned it's coming up in other places as well.

I came to report this, found the issue instead.

This particularly affects my day to day flow, since I use bookmarks to administrate my web novel reading, which means I can trigger the bookmark menu upwards of 50 times a day. I usually have the Table of Contents for the novels open in one tab, and the chapters in another. Once I catch up with the novel released chapters I try to go back to the Table of Contents and press Ctrl+D/CMD+D to update the latest read chapter.

However, I often end up on another tab by accident, but already pressed CMD+D/Ctrl+D by muscle memory, so it ends up bookmarked. 

Not having a button to quickly undo this is quite annoying. I don't particularly mind if you decide escape should be "close this window" rather than "Undo". But I would really love to have a button, any button (Maybe Del? Although that's unavailable in a few keyboard models), available to quickly cancel. 

Also considering Escape to cancel a bookmarking action has worked for so long it does severely mess up my mental model when this keeps changing.

ainslie@ and hwi@ - what about the command Bookmarks -> Bookmark This Page changing to Unbookmark This Page when the current page is already bookmarked? The (default) keyboard shortcut would remain Cmd-D, so if you pressed Cmd-D by mistake, pressing Cmd-D a second time would undo it.

shrike@ If you mean pressing CMD + D once the bookmark menu is already open to unbookmark, I'm all for that.

However, if you mean visiting a site that is bookmarked and having pressing CMD + D remove it that would completely destroy me.

Let me illustrate my flow:

1.- I go to a content aggregation site for novels (I use novelupdates, some people use extensive RSS lists). 

2.- I open the bookmark URL in a new tab

3.- I open the chapter URL in a new tab

4.- I tab over to the chapter URL and read the chapter

5.- I close the tab, I (usually) land in the bookmarked page, with the Table of Contents

6.- I press CMD + D to open the bookmark menu, something like "The King’s Avatar 679" is highlighted.

7.- I change that to "The King’s Avatar 680"

8.- I press enter

Is keeping track of relative progress uncommon for Bookmarks? I understand that if my flow is incredibly niche catering to it is not a priority. But I still feel I should put this out there so that this kind of behavior goes into consideration when considering the changes.

Thanks for use cases, ideas, and discussion. 

re: c19, here's a follow-up. pkasting@, thanks for the discussion. Please feel free to chime in. 

The Bookmark Star dialog's Esc behavior is inline with the current/Harmony recommended rules(see below). An issue is that there's no easy-way using keyboard to undo the action that's made unintentionally as noted on c#20. We need to find a solution that's specific to Bookmark Star rather than changing the Esc behavior recommendation. 

Here are currently collected ideas to easy-undo:
- Repeat Ctrl+d to unbookmark: this breaks Editing use case (c#22)
- Repeat Ctrl+d while the first instance of bookmark dialog is open
- Don’t show any dialog on the 1st Ctrl+d, and 2nd Ctrl+d does undo 

and more ideas are welcome.  


=======
Current/Harmony recommended rules:

This is the current set of rules for Esc, and Harmony intends to continue to support it:

a. Pressing Esc always dismisses the active/focused dialog regardless of presence of Cancel or Close_X button. 
b. Pressing Esc never takes any additional actions other than dismissing a dialog.

Rationale/assumption: Esc being used to dismiss a dialog is commonly understood and expected. It’s less commonly expected for Esc being used to map to a certain button or to undo action. Mapping multiple actions to a single keypress could end up causing different mental model build-up.

For ongoing reference/refinement: go/harmony-esc (note: this is not a public doc) 

Another option might be to fix the root cause of people accidentally hitting Ctrl-D / Cmd-D: Allow using "/" as an alternative to Ctrl-F to open the find feature, like Firefox does.

See  Issue 162544 

> - Don’t show any dialog on the 1st Ctrl+d, and 2nd Ctrl+d does undo 

This doesn't work.  This would mean that when people create a bookmark they wouldn't know which folder they'd created it in.

Sometimes intuitiveness should take a priority over consistency.

I think the core issue is that everything about the "bookmark added" dialog goes against what you'd expect, i.e. it is a fundamentally wrong dialog. The natural expectation is that pressing ctrl+d either bookmarks the page or brings up a dialog to bookmark the page.

The current behavior is that ctrl+d bookmarks the page and brings up a dialog to _modify_ the bookmark you just (already, you have no say in the matter) created.

I would argue that is the real problem and it's why it's so difficult to find an intuitive solution for undoing the bookmarking. 

If you were to start over and ask what is actually intuitive behavior, it is that ctrl+d or clicking the star are both dialogs that _will result_ in adding a bookmark, not dialogs that pop up after the fact. Dismissing those dialogs (via clicking elsewhere or via escape) would be 100% in line with harmony ui suggestions: no bookmark was added so dismissing it only hides the dialog and no additional action (or un-action) is taken.

Chrome is too bookmark-happy here.

As mqu...@ mentioned, in retrospect this (arguable) regression is rooted in the fact that ctrl/cmd + d instantly bookmarks, rather than having the modal dialogue be a bookmark creation tool, it is a "Edit the bookmark you just created" tool. 

Whether this is intuitive is arguable. I think normal modal expectations are that the "Saving" happens when you click "Save/Done/etc", so this model of having it bookmark first, and having the resulting modal be an edit modal, rather than a creation modal might be counter intuitive to begin with.

Under the current scheme, having the escape button behave as it does follow harmony, because Ctrl/Cmd + d instantly saves. But as mentioned, the base behavior of having Ctrl/Cmd + d save, and the modal being an edit operation rather than a create operation might be something worth reviewing.

I don't have access to the harmony documents, so I don't know if you have internal guidelines for modal creation behavior. 

====
This referenced what hwi@ posted above:

Current/Harmony recommended rules:

This is the current set of rules for Esc, and Harmony intends to continue to support it:

a. Pressing Esc always dismisses the active/focused dialog regardless of presence of Cancel or Close_X button. 
b. Pressing Esc never takes any additional actions other than dismissing a dialog.

Rationale/assumption: Esc being used to dismiss a dialog is commonly understood and expected. It’s less commonly expected for Esc being used to map to a certain button or to undo action. Mapping multiple actions to a single keypress could end up causing different mental model build-up.

For ongoing reference/refinement: go/harmony-esc (note: this is not a public doc) 

> FWIW, when I turn on MacViews, cmd+. also dismisses the bubble, but keeps the bookmark, which is extra weird: not all dialogs respond to cmd+. (I think), but, when they do, it should be the negative action (and generally the same action as esc).

Cmd+. is mapped to 'Stop' in Chrome's View menu, which will divert key handling away from calling cancelOperation:. Instead IDC_STOP gets sent to the parent browser window, similar to how Cmd+t/w/{/} behave.

As for Alt+r (when --secondary-ui-md pops a bookmark_bubble_view.cc) - we don't currently do anything special to _suppress_ the Alt+r accelerator that bookmark_bubble_view.cc adds, but Alt+r or Mac sends a "®" and the accelerator is for "r" not "®", so nothing happens. Which I guess is good :). If it did something, a user wouldn't be able to type "®" in the input field with Alt+r on Mac since the accelerator handling would pick it up first.

If we want another accelerator, Cmd+r isn't good, since that's "IDC_RELOAD" on the parent window. Ctrl+r would work (it currently sends `noop:`), but it's not really discoverable. Also some Ctrl+letter combinations (e.g. 't') send editing commands (i.e. 'transpose:'), so it's not generalizable behavior.

Recent versions of macOS use cmd+backspace for Delete/Don't Save in dialogs. If we're looking for an accelerator, I think that would be a good choice.

I still *personally* find combining "bookmark first, then edit" with "esc dismisses" confusing, and that only adding the bookmark once you confirm would be less confusing, specifically because the bubble is modal. It's like if deleting a bookmark brought up keyboard-focus-taking bubble with "OK" and "Undo" buttons:

    ----------------------------------------------
    |  Bookmark Deleted                          |
    |                                            |
    |  ----------                        ------  |
    |  |  Undo  |                       || OK || |
    |  ----------                        ------  |
    ----------------------------------------------

MD bookmarks does show a toast with an undo button after you delete a bookmark, but it doesn't take keyboard focus, so it doesn't surprise me in the same way.

Leaving this as Available, but it perhaps should be WontFixed.

This was (sadly) intentional. estade may remember the bug with more details.

https://codereview.chromium.org/1953943003