Thanks for the report. Can you reproduce it in latest Chrome Canary 72?

Maybe it is already fixed there because a lot of key-press issues were solved in the meantime.

Thanks in advance.

Works fine on Canary 72

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Unable to reproduce the issue on mac 10.13.6 and mac 10.14.0 using chrome reported version #70.0.3538.77.
Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Started autocompleting URL in the address bar, e.g. github.com/my-org
2. Started typing "gith.." and select github.com/my-org from inside of the address bar by pressing the the right arrow key on my keyboard.
3. Observed that the text cursor jumped to the end of autocompleted URL when the right arrow key was pressed as expected.

chingis@ - Could you please check the attached screen cast and please let us know if anything missed from our end. Also please check the issue by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.

Thanks...!!

Deleted: 899597.mp4 839 KB

	899597.mp4 839 KB View Download

Ok, there's more to this bug:

1. Open travis-ci.org in the first tab with autocomplete, right arrow key works
2. Open travis-ci.org in the second tag with autocomplete, right arrow key does not work

Tried to reproduce it with github.com, did not work however it worked with github.com/my-org, i.e. when a tab with this URL already opened the right arrow key in autocomplete won't work in the second tab. I've recorded the video but there's nothing to it.

I tested under the new clean profile.

Screen cast file attached.

Deleted: chrome-right-arrow-key-bug.mov 3.0 MB

	chrome-right-arrow-key-bug.mov 3.0 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Looks like a tab switch issue.

It's a little hard to tell from the video, but I assume what's happening is that, a tab switch button is being offered, and right arrow is highlighting the button. If so, then in a sense, this is WAI.

However, we obviously want the user to be able to add text past the autocomplete (not just hit enter), so what we should do is verify that the entire selection is at the end of the string, not just one end.

A temporary work-around here would be to hit End.

You're right, now I see "Switch to this tab" is selected, I didn't pay any attention to it because I never look at the right side of the screen while autocompleting, especially on 27" display. 

So it's a new feature that shows that you already have this URL opened and you can switch to this by selecting it with the RARROW key and pressing space. Ok, I get it now but this breaks a typical text selection behavior on any system – if you have text selected, RARROW key will place the text cursor at the end of the selection. Works everywhere but doesn't work in Chrome address bar, that's a bad UX, IMO. Besides you can select this element by pressing TAB, do we really need a RARROW? 

Hi chingis@, As I said, the user should be able to arrow to the end and edit. I will simply restrict the arrow focus to only when the selection is fully at the end. So in this autocomplete condition, arrow would first move the selection all the way to the end, where the user could either edit, or press it again and focus the button. (But this may not hit stable for a while.)

Ok, thank you. Although I find the selection with RARROW key unintuitive regardless of the text cursor position, I think very few people will notice that some element was selected somewhere at the right part of the dropdown. For those who want to use it, there's always TAB – intuitive and standard. Otherwise, you're forcing people to use a feature that useful in very narrow cases. 

It looks like the issue is already being investigated and behavior of this has already been identified. Hence, removing the Needs-Bisect label. Please feel free to add the same if required.

Thanks...!!

Hi chingis@, The tab key does several things in the Omnibox too, so regardless we would have had to overload.

The reason why the arrow keys do anything at all is because up and down move the selection through the suggestions. So if the tab switch button was present, it was felt that it would be intuitive if you could move left and right there too (assuming the Omnibox was in the right state.)

I think once this is fixed that you'll find it more friendly.

I also ran into this issue and determine that the new "switch to this tab" button was the culprit. This new feature introduced a breaking change for user experience any was annoying enough for me to track down what was causing it and submit an issue (luckily I searched first and found someone else already did).

As a workaround until a fix can be released (since it was previously noted that a fix may not hit stable for a while) you can disable the Omnibox tab switch suggestions feature by going to chrome://flags/#omnibox-tab-switch-suggestions and disabling it.

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

commit 392fcdcbfef641404750d81a2263c379267e480e
Author: Kevin Bailey <krb@chromium.org>
Date: Fri Nov 02 21:02:24 2018

[omnibox] Fix arrow key behavior with Omnibox

This change includes 2 fixes:
 - When text and UI direction don't match, focusing the tab switch
button homes the cursor in the Omnibox. Now the cursor remains where
it is. (900244)
 - When there is autocomplete text and a tab switch button showing,
right arrow doesn't go to end. Now we check that the selection is
entirely at the end before consuming right arrow for the tab switch
button. (899597)

Bug:  899597 , 900244
Change-Id: Ib5c953d22c1b80f6f516a04d8e12e7d8b5b13c19
Reviewed-on: https://chromium-review.googlesource.com/c/1312983
Commit-Queue: Kevin Bailey <krb@chromium.org>
Reviewed-by: Justin Donnelly <jdonnelly@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605048}
[modify] https://crrev.com/392fcdcbfef641404750d81a2263c379267e480e/chrome/browser/ui/views/omnibox/omnibox_view_views.cc
[modify] https://crrev.com/392fcdcbfef641404750d81a2263c379267e480e/chrome/browser/ui/views/omnibox/omnibox_view_views.h

 Issue 901793  has been merged into this issue.

Issue 903547 has been merged into this issue.

 Issue 916231  has been merged into this issue.