This might be specific to macOS; I'm currently on Chrome OS and Alt+Enter seems to be behaving correctly.

I don't think this is a security vulnerability, just a functional bug.

Assigning to avi@ for triage, as it appears to be Mac specific bug.

Right, I don't think it's anything that could allow someone to intentionally do something malicious with someone's browser. More like it could cause someone to accidentally do something dangerous with their own browser.

If it doesn't happen on Windows v69 with Alt+Enter, that should make it easier to track down for Mac v69.

Alt+Enter on Windows doesn't appear to be equivalent to Command+Enter on Mac.  Alt+Enter on both Windows and Mac navigates in a new tab in the foreground, which resets the URL of the original tab when you switch back to it.  Shift+Enter also doesn't show the problem.

Command+Enter on Mac (and Search+Enter on ChromeOS, and apparently WindowsKey+Enter on Linux but not Windows) seem to navigate in a background tab, which doesn't clear the typed URL afterward.  I would imagine we should reset the URL in that case, but I'd defer to pkasting@ or mpearson@.  I'm not sure if that clearing logic would be on the omnibox or navigation side.

This is designed behavior, though I could be convinced it's designed wrong.

The closest Windows equivalent is middle-clicking a dropdown entry.  It opens a new background tab and allows you to keep interacting with your current typing.  The intended use case is e.g. opening several search suggestions in background tabs.  If you wanted to terminate your action, our rationale is that you could have used alt-enter (which does reset the state of the origin tab) or hit esc.  But if we make it reset by default it's far more inconvenient to try to open multiple dropdown items.

Right - as I mentioned, this seems to be a new-ish behavior in Chrome OSX, as I've been using the same feature for years, and I've only noticeably encountered risky situations with it recently. I don't know if the open-in-background behavior is a new thing or not.

pkasting - is there an alternate key combo that I should be using, that would open the tab and reset the URL? I'd happily use that, but I'd also argue that Cmd+Enter is the command I've trained myself to use for that (coming from Alt+Enter in Windows), and I'd expect some combination of them to work the same. This is also why I'd be OK with an alternate approach, where the omnibox UI gives me some sort of indication that what I'm currently seeing in there, doesn't actually correspond to the page that I'm seeing.

Seems that Option+Enter on OSX opens the new URL of the tab in the foreground. Can we get a quick regression check of that related code, to see if the current URL-resetting behavior of Cmd+Enter has always been the case in OSX? If so, I'm OK with knowing this going forward. If not, I'd argue that the new behavior should actually be the one assigned to Option+Enter.

Option-(aka Alt)-enter opening a new tab in the foreground is consistent with other OSes, and having cmd-enter open a background tab is consistent with cmd-clicks in web pages.  I don't know offhand if the cmd-enter behavior is consistent across time in OS X (I don't have the ability to check that easily), but I know we wouldn't want to move alt-enter on Mac away from what it is on Windows.

It's rather unfortunate the Mac keyboards place the cmd key next to the spacebar where the Windows alt key is, and place the actual alt key next to it.  But I think mapping by key location and ignoring the key name is arguably more confusing than what we're doing now.

OK. If it's possible to see what the previous behavior of that key combo is, that'd probably be useful. I get the intent of keeping the key combination mapped to the intended usage of that modifier key. At the same time, though, the key placement isn't trivial. I'd argue that keeping the behavior consistent wrt muscle memory and consistency of user experience across OSes is more important than keeping the implementation in line with the key name.