Able to reproduce the issue on the latest canary(61.0.3159.0) on Mac OS 10.12.5. 

Regressed in M-61.

Last good build: 61.0.3115.0
First bad build: 61.0.3116.0

Changelog:
==========
https://chromium.googlesource.com/chromium/src/+log/aa76e566cab7436963a2d12312173cbd0339093d..1f35c3ffdebd60917647555ac6ec572098967035

Assigning to jdonnelly@ for further inputs and if present behavior is WAI.

The proposed behavior makes sense. I'll try to take a look at it this week.

A friendly reminder that M61 branching and Beta promotion is coming soon! Your bug is labelled as Beta ReleaseBlock, pls make sure to land the fix ASAP to trunk. This way we branch M61 from a high quality trunk. Thank you.

Friendly ping to get an update on this.

shrike: could I get your opinion on this question?

Chrome and Safari share the behavior that when the omnibox/location field are in an edit state, the edit state persists even if the field loses focus and even if you switch tabs. Safari stays in the edit state after Cmd-Return but *then and only then* reverts the edit state when the location field loses focus.

In other words, it has some additional state representing whether a Cmd-Return has been performed or not.

I'm really reluctant to do the same thing. Focus and edit state is already quite complex and I think adding more state is asking for bugs. Do you have any thoughts on which of the following would be the best thing to do?

- Keep the current behavior.
- Revert to the old behavior (always immediately revert edit state on Cmd-Return).
- Add more state in an attempt to match Safari's behavior.

(FWIW, as a user I find the old behavior or Safari's behavior pleasant, and Chrome's current/new behavior annoying. Reverting edit state on Cmd-Return doesn't sound too complicated to me, but as I mentioned above, I don't have full context on the original motivation for this change.)

I think keeping the edit state as long as the omnibox has focus is not unreasonable, and as you note, is inline with that Safari does.

Keeping the edit state when the omnibox loses focus seems problematic, because there's no way to "undo" that as far as I can tell. For example, if I

1. Go to apple.com
2. Type puppies and then Cmd-L
3. Click the new tab
4. Click the apple.com tab

the omnibox now says "puppies" and I can't get back to the apple.com URL, which means, for example, I can no longer see or access the security state. The contents of the omnibox also no longer corresponds to the contents of the page. I guess we accept that when we're typing new contents into the field but it seems wrong to also accept that when the field is not being edited.

So we should either revert to the previous behavior or do what Safari does.

> In other words, it has some additional state representing whether a Cmd-Return has been performed or not.

Is that true? For example, if I

1. Go to apple.com
2. Type puppies and then Cmd-L
3. Press Esc

I get back apple.com. It seems like the solution would be to restore the omnibox (i.e. essentially take the Esc path) when switching tabs will cause the omnibox to lose focus.

Sorry, I don't quite follow a couple of these comments.

> Keeping the edit state when the omnibox loses focus seems problematic, 
> because there's no way to "undo" that as far as I can tell.

Maybe I'm not understanding the case you're referring to, but you should always be able to see the URL and security state again by pressing Esc.

Note that remaining in the edit state (whether by putting focus on the page or switching tabs) is intentional so that you can go read or copy other text that you'd like to then put in your edit session. And except for the Cmd-Return case, this is true of both Chrome and Safari. And both can cancel the edit state with Esc.

> > In other words, it has some additional state representing whether a
> > Cmd-Return has been performed or not.

> Is that true? For example, if I

I don't follow your example, insofar as it doesn't include pressing Cmd-Return.

> It seems like the solution would be to restore the omnibox (i.e. 
> essentially take the Esc path) when switching tabs will cause the 
> omnibox to lose focus.

Granted, that is a 4th option. But it will lose some functionality and deviate from Safari's behavior in this case.

If I

1. Go to apple.com
2. Type puppies and then Cmd-Return
3. Click the new tab
4. Click the apple.com tab

the omnibox is no longer in the editing state. It seemed that there was no way to get back to the previous omnibox contents, but I see that if I

5. Click in the omnibox
6. Press Esc

I can get back to the previous omnibox contents. However, as I noted above, it doesn't make sense for the omnibox to display a string that does not correspond to what I see in the tab (unless I'm actively typing it). So I think the behavior should go back to what it was, or the omnibox should revert to its previous content before losing focus on tab switch.

> Granted, that is a 4th option. But it will lose some functionality and deviate from Safari's behavior in this case.

How does Safari behave differently? This seems to be exactly what Safari does.

> How does Safari behave differently? This seems to be exactly what Safari does.

That's exactly what Safari does in the Cmd-Return case. But if you do the following:

1. Go to apple.com
2. Type puppies
3. Create a new tab
4. Click the apple.com tab

Safari's location field will still be in the edit state, displaying "puppies".

We would either have to lose this behavior by always reverting the edit state on tab switch or focus loss. Or add additional state to revert the edit state or not based on whether Cmd-Enter has been used or not.

Regardless, I think for now I'll just revert the latest change and return to the previous behavior so that this issue doesn't appear in M61 and then we can decide what, if anything, we want to change going forward.

Revert: https://codereview.chromium.org/2983193002/

I think making Cmd-Return not reset the omnibox state is reasonable. I think there's only a problem if the omnibox loses focus but preserves the editing state. 

Following the steps in c#11, in M-60 the omnibox is in the editable state at the end but in M-61 the omnibox is not in the editable state at the end. If the cl can be reworked to not change the omnibox's behavior (i.e. changed so that it leaves the omnibox in the editable state at the end) that seems like it would address the issue of this bug report.

This is no longer an issue on the latest available M-61(61.0.3163.8) as tested on Mac OS 10.12.5 due to the revert of the CL https://codereview.chromium.org/2983193002/.

jdonnelly@: Shall we remove the Beta blocker for M-61 as the CL is already reverted.

Yup, thanks.

Given the plans for MacViews, I'm reducing the priority of this and will probably close it later.

The correct command-enter behavior has been added to MacViews. It doesn't exhibit this issue, as it leaves the omnibox in the edit state, with focus after command-enter and when switching between tabs. See  https://crbug.com/838966  for details.

Closing this issue as obsolete.

The NextAction date has arrived: 2018-09-20