I can reproduce this on Mac as well. Weirdly, though, I *can't* reproduce this on the exact same version on Win10 (72.0.3616.0 (Official Build) canary (64-bit)).

orinj: can you take a look at this? What *should* be happening here is that when repeated tabbing moves focus to the omnibox, the contents should be selected but the popup should not open. I can't recall for sure, but I think there's something in the code that specifically suppresses the popup in this case.

You can see the desired behavior by navigating to any web page and hitting tab enough times (shift-tab may be quicker) until focus moves to the Chrome UI and eventually to the omnibox itself.

If it's not obvious what's going on here, let me know and I try to help track it down.

Works in development.  I tried on both Windows and Linux, using the given PDF link.  Some possible reasons:
* It could have been a transient issue that is now fixed.
* More likely, there is something special about the testing environment that triggers the bug: history, profile, settings, ...

So it would be helpful to try and capture the state of a machine that can repro.  Or at least understand enough history of what was done so that I can get mine into a broken state.  Once I can repro, I can begin to debug.  For a start, it might be worth checking if the newer versions still exhibit the problem... if so, then try running with a clean profile to see if it might be related.  To do that, run with something like:

chrome --user-data-dir=$HOME/profiles/test1

Here are the versions that exhibit correct behavior in my testing:

Chromium
73.0.3632.0 (Developer Build) (64-bit) 
Revision
cc19edbe4b1d7899d5e3f3cf93cca71b6d0e5603-refs/heads/master@{#614036}
OS
Windows

Chromium	73.0.3631.0 (Developer Build) (64-bit)
Revision	f8746079c0456d3b4091e7d06fd05856691a5bb7-refs/heads/master@{#613670}
OS	Linux

I think I've figured out what the issue here is. This is being caused by zero suggest. At least, that's what I'm currently seeing. When you focus the omnibox, the popup opens with a bunch of generic PDF-related suggestions (see attached screenshot).

This may not matter as we're considering turning down zero suggest. But I'll leave this open and assigned to me in case we want to continue or do zero suggest in some other form. We'll want to consider this case.

In the meantime, there is a workaround. When the popup opens, press esc (may have to press esc twice) to close the popup. Tab will then move focus to the next element as expected.

Here's the attachment mentioned in Comment 4.

Deleted: Screen Shot 2018-12-11 at 10.43.53 AM.png 185 KB

	Screen Shot 2018-12-11 at 10.43.53 AM.png 185 KB View Download

Configuration state bites again. :)  Is there a process for transferring state from one Chrome instance to another so they can work with the exact same experiments, configuration, etc.?  We can't share profiles for privacy reasons, but at least we should be able to have testers manually "Report Configuration to Bug" when they have an instance that can repro the bug... with enough such reports, we could narrow down the offending configuration; and even with one report, a developer can repro by downloading from the reported config URL.  This would be supported by a server and internal dev tool.

Does anything like this exist yet?

I've implemented these kinds of systems in the past, and they really make debugging systems easier by orders of magnitude.

Usually everything that matters in terms of "I see this feature, but you don't" is captured by the "Variations:" section of chrome://version. See go/finch-debugging for more details.

I've certainly seen a fair number of cases where there were reproducibility issues that were profile-data-specific, but as you point out, we can't collect those.