As this being a Non-Regression issue, changing the status to Untriaged so that the issue would get addressed.

Thank You!

It seems to me there's some additional complexity to consider here. In ActualVideo, the UI is laid out RTL but the text editing is still LTR. The user is pressing the left arrow key expecting focus to move to the button, but the cursor is still in the middle of the text. So, given the rules we apply in LTR, focus *shouldn't* be moving to the button. Only if you left arrowed all the way to the left edge of the URL text would you then expect focus to move.

The LTR text may be just because it's a URL, though. If it's query text, does the text then lay out RTL? In that case, the cursor would be on the left edge by default and a left arrow could move focus to the button (using the approach in https://crrev.com/c/1280847).

But if the text is always laid out LTR, I think we could only move focus if the cursor was moved all the way to the beginning of the text and *then* the user pressed the left arrow key.

When the text is LTR but the UI is RTL, I agree it looks a little weird to hit left arrow and have the focus change. However, it's basically fine if it's what you're expecting.

If that's too weird, we could simply disable arrow keys for focus change in this configuration.

The other combinations look ok to me.

(I should clarify that the above observations are with my trial CL.)

I'm not clear on what behavior your CL produces, though. It requires SelectionAtEnd before allowing the left arrow key to operate. If "end" in this mixed RTL/LTR sceanario still is the rightmost edge of the text, then that means a left arrow there would move to the button instead of moving the cursor within the text, which would be bad.

> The other combinations look ok to me.

Can you enumerate what the other combinations are and what happens in each?

> left arrow when rightmost

Latest CL should handle all the cases correctly.

> Can you enumerate

Kind of messy when there's 4 binary values, but here's an attempt at what it should do:

LTR UI, LTR text, right arrow, at end (rightmost) - focuses
LTR UI, LTR text, left arrow, (regardless) - unfocuses
LTR UI, RTL text, right arrow, at beginning (rightmost) - focuses
LTR UI, RTL text, left arrow, (regardless) - unfocuses

RTL UI, RTL text, left arrow, at end (leftmost) - focuses
RTL UI, RTL text, right arrow, (regardless) - unfocuses
RTL UI, LTR text, left arrow, at beginning (leftmost) - focuses
RTL UI, LTR text, right arrow, (regardless) - unfocuses

I'm still seeing a tiny problem which I suspect is not related to this: When the user unfocuses, it doesn't consume the arrow key. I'm also seeing the cursor jump from one end to the other at times.

Thanks for laying out the cases clearly.

The fact that you removed the SelectionAtEnd() condition for unfocus is inspiring a new thought in my mind. What if we didn't care about the cursor position at all? Let the left/right arrow keys focus/unfocus as appropriate for the UI direction and then just didn't consume the event (return false)? This would result in a single key press doing both things (moving focus and moving the cursor).

The reality is that the user is actually trying to do one or the other, depending on where their attention is. What we're doing now potentially could confuse as to why the expected action isn't happening. Whereas if we do both the user will always see the expected outcome and maybe not notice that another thing elsewhere also happened. Thoughts?

As I mentioned in #7, when it didn't consume the arrow key, I noticed immediately. Certainly, we could train people that's ok, but we'd field some bug-reports until then. I don't see the benefit?

After a discussion, we agreed that clicking in the Omnibox (to change the cursor position, for example) should unfocus the button. The latest patch does this.

There's a tiny problem compounded by this policy. There's a bug when the language doesn't match the UI direction. In this condition, arrowing to focus moves the cursor to the other end (the beginning) of the text for some reason. With the 'at end' policy, you therefore can't immediately unfocus. You have to move the cursor all the way to the end and then unfocus; without an 'at end' policy, you could immediately unfocus.

Filed crbug.com/900244

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

commit 5f2cc6d8103e545960e56f845cbfa97268d5f2b6
Author: Kevin Bailey <krb@chromium.org>
Date: Thu Nov 01 17:20:02 2018

[omnibox] Reverse arrow keys for RTL with respect to tab switch button

In a RTL UI, we'd like the arrow keys to behave intuitively which means
they must be reversed from in LTR mode. Also, it makes a slight behavior
change: To handle the case of not being able to unfocus the button if
the cursor is moved away from the end, we now unfocus the button as
soon as the Omnibox is clicked (which makes sense in terms of moving
the "focus".)

Bug:  894788 
Change-Id: I3323a5b2575bdbaad45853799044f21efa65ac63
Reviewed-on: https://chromium-review.googlesource.com/c/1280847
Commit-Queue: Kevin Bailey <krb@chromium.org>
Reviewed-by: Justin Donnelly <jdonnelly@chromium.org>
Cr-Commit-Position: refs/heads/master@{#604624}
[modify] https://crrev.com/5f2cc6d8103e545960e56f845cbfa97268d5f2b6/chrome/browser/ui/views/omnibox/omnibox_view_views.cc
[modify] https://crrev.com/5f2cc6d8103e545960e56f845cbfa97268d5f2b6/chrome/browser/ui/views/omnibox/omnibox_view_views.h

Update :

Rechecked the above issue on Windows(7,8,8.1,10), Mac(10.13.1 , 10.13.6, 10.14.1) and Linux (14.04 LTS)OS with latest Canary version #72.0.3599.0 and observed that once user brings focus on to the suggestion with the 'Switch to this tab' button and then clicks left, then after traversing the entire URL string in omnibox using left arrow key the blue focus ring appears on 'Switch to this tab' button , hence, we can say issue is fixed

Kindly refer the attached screen cast.

Deleted: CanaryBehaviour.mp4 570 KB

	CanaryBehaviour.mp4 570 KB View Download