…It's worth noting that this is already Chrome's behavior in fullscreen.

Seems reasonable (though you shouldn't do anything while the omnibox dropdown, bookmarks dialog, or anything else are visible).

What do you mean by blurring?

By blurring, I mean making the web contents the first responder.

If this makes sense to do on the Mac it makes sense to do on all platforms.

sdy: assuming you're successful with your Cocoa change, assign this to me when you're done and I'll investigate how we might do the same thing on Views.

I agree that this provides a legitimate user benefit.  However, this is also problematic for three reasons.

First, on principle, using escape to change focus is unusual.  Escape generally changes focus only as a side effect of e.g. closing a dialog (by canceling it).  Changing focus in this situation seems without precedent in our UI.  It would be better to e.g. ensure the web content is in the tab order (and, ideally, next after the omnibox), so users can use the standard focus-changing keys to handle this.  (Alternately, we could create a new shortcut to focus the web content, or make ctrl-L toggle between omnibox and web content, but these routes have their own issues.)

Second, esc is a multi-level cancel in the omnibox -- for example, escaping when there's temporary text reverts to the user text, and escape again reverts to the permanent text.  Therefore, users (including me) sometimes hit escape repeatedly to make sure to bail out of all edit states.  This would break that by changing focus when you were simply trying to get back to the start of your edit state.

Third, when the user is not editing, escape is supposed to map as a browser shortcut to "stop current page load".  At the very least, this takes a key whose meaning is already multiply overloaded and adds another overload; at worst, it would break that functionality entirely.


The argument about fullscreen mode is an interesting one, and one that defies comment 6 a bit.  Fullscreen mode on Mac is a unique UI using a temporary overlay, almost like a dialog.  It makes some sense for esc to close this "dialog", not as a function of focus being in the omnibox specifically, but as a function of having any part of the dialog be focused; and then focus going to the web content as the dialog closes is a natural side effect.  When the overlay UI is not present, as in the non-fullscreen and non-Mac cases, this argument does not apply.

Given all this, I recommend WontFix, on Mac and other platforms.  The current behavior is the most correct.

pkasting: some thoughts on your three problems:

The first issue is actually what motivates this in my mind. The omnibox acts much like a dialog (as illustrated by ainslie's mocks* which depict something functionally identical to the interactive omnibox but actually looks like a dialog). The case in question is moving focus from the page to the omnibox via Alt-D/Ctrl-L/Cmd-L. This is not advancing back or forward through the tab order so using tab order to reverse this action isn't intuitive or principled. On the other hand, moving to the omnibox is much like opening the save page dialog via Ctrl-S. It's orthogonal to any tab order and if I decide I've changed my mind, esc is the expected way to back out.

(Separately, I was chatting briefly with sdy about this and apparently there is something of a platform convention for using esc to cancel text field focus on Mac. I imagine he can provide more detail if you're interested.)

The second issue is compelling but should be balanced against the current failure mode. I regularly find myself hitting esc expecting it to cancel a switch to focus on the omnibox and being disappointed that it didn't work. I can't even speculate as to which failure mode (esc doesn't do what I expect, too many escapes would "overshoot" the target for you) is/would be more common but note that mine has no solution at present. Whereas yours could be addressed by pressing Ctrl-L to move back into the state you were aiming for). Whether you find that argument compelling or not, it'd be nice to at least experiment with this (perhaps just on Mac) to see how it works in practice.

As for the third problem, I don't see why overloading esc is an issue since it already cancels page load and cancels edit states. And closes dialogs.

* Slides 11-23 at: http://slides/1MdqUPSU4D8AheCKz0S5PHTlfkf7F2x07gghcNZbAGRw/edit#slide=id.g1c44df0e3e_0_159

In ainslie's mocks, it would make sense for hitting esc to put focus back wherever it was.  But in the current UI, I disagree that that makes sense as a UI paradigm.  The current omnibox is not a dialog, it is part of the same Chrome window you're already in.  It does not z-order stack atop what you were previously doing temporarily, and is not dismissed when you hit esc.

I can't speak to "cancel textfield focus on Mac".  If that's something which makes this a common convention there, that would be an argument for pursuing a Mac-specific behavior.

As for the commonality of failure modes, I've never encountered the case you're describing, which is biasing my reactions -- but I also think commonality is the wrong lens from which to approach this.  UIs need to behave in a consistent and principled way.  Hitting esc to move focus from one field to another within the same window is unprecedented on Windows; if this is a real problem, I believe we'd need a different solution.  (My suspicion is this is not a significant enough problem to create such a solution.)

The convention mostly shows up on Mac when you have a search field in a toolbar (but I might be able to come up with other cases). I attached a gif showing System Preferences, and I want to use that example to argue that it's consistent and principled to use the esc key this way.

When the search field is idle, the icon and placeholder text are positioned like they would be on a button. When it gains focus, they shift into positions that make sense for a text field. This is conceptually equivalent to having a button in the toolbar which replaces itself with a text field, or shows a drop-down search bar (like Chrome's).

In Chrome, the esc key dismisses the search bar and returns focus to the web content not because it's stacked atop the web content, but because it's an accessory to the content. The omnibox also has two modes: when idle, it shows the origin of the current page, when active, it lets the user enter a URL or search term. In Safari the difference is more pronounced — it hides the path and centers the origin when idle — but Chrome's omnibox serves the same two roles. Esc doesn't blur a text field — it dismisses the omnibox's editable form and replaces it with a static one which happens to look very similar.

As for failure modes, I encounter this case pretty often, for what it's worth — I want to enter something in the omnibox and press cmd+L, then either change my mind or use cmd+enter to open the thing in a tab behind the current one. In either case, I don't have a way to get keyboard focus back to whatever had it in the page (like a text field).

Deleted: esc_from_field_system_preferences.gif 1.2 MB

	esc_from_field_system_preferences.gif 1.2 MB View Download

I am perfectly prepared to believe that this is a coherent Mac-ism, I'm just uncomfortable expanding it to other platforms.

That said, I think it is not quite true to say that the omnibox has separate idle/active modes; if we did, we'd clear the omnibox contents on focus, since we know (from past research) that having existing text in the field hinders users using it to enter new terms.

OK. Adding it on Mac is good enough for me, since I don't know the conventions on other platforms well enough.

That's fair (to say that the omnibox doesn't quite have separate idle/active modes) :).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/43aae2eb1c0048443598bfcb11fd428862f3af09

commit 43aae2eb1c0048443598bfcb11fd428862f3af09
Author: Sidney San Martín <sdy@chromium.org>
Date: Mon Oct 23 18:23:49 2017

Make esc always return focus from the omnibox to web content, not just in fullscreen.

Bug: 776080
Change-Id: Ic6ee1ee1384deea5a9740104dad79dc3d7146ea7
Reviewed-on: https://chromium-review.googlesource.com/544277
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Sidney San Martín <sdy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#510854}
[modify] https://crrev.com/43aae2eb1c0048443598bfcb11fd428862f3af09/chrome/browser/ui/cocoa/location_bar/autocomplete_text_field_editor.mm

jdonnelly@: Over to you for Views/noop!

There is a long-standing bug related to this: https://bugs.chromium.org/p/chromium/issues/detail?id=92885

My vote is for making esc behave as suggested on all OSes, since I have equal frustration for this on Mac and Linux, although I understand the objections raised. We need *some* shortcut to achieve this on each OS, and preferably one that is cross-platform.

 Issue 836363  has been merged into this issue.

Also worth noting that MacViews regresses the Mac fix, so either this should be changed universally or we need a new Mac-specific change.

FWIW, I somehow expected this to be the case and thought it was a regression with the new UI (it's not, so I'm confused how I ever taught my fingers that ESC + content-destined key (e.g. 'i' in Inbox) would work).

I like the cross-platform proposal for ESC in omnibox in the OP (even though I have little weight in UX decisions :))

FWIW, I think a second ESC to hand focus back to the web content would be nice. 

https://groups.google.com/a/google.com/forum/?utm_medium=email&utm_source=footer#!msg/pizza-teamfood-discuss/fwxsSDZyhJI/9OQWYGHlCAAJ

 Issue 882492  has been merged into this issue.