RenderTextTest.MoveLeftRightByWordInBidiText is currently disabled for OS_WIN.  In trying to enable it, I've made some progress, but I'm running into difficulties, and I think some may be bugs in the underlying selection model.

Here's one test case I tried.
(1) Copy the Hebrew letter Resh: ר
(2) Type the following string in the omnibox but paste Resh where you see R: RRR abc RRR abc
(3) Select all and paste that same string into Visual Studio's text editor
(4) Trying using ctrl-left/right with and without shift in the two.  Visual Studio behaves pretty sanely; the omnibox does not.
(a) Example: Place your cursor within the logically second (physically left-hand) group of Reshes.  Repeatedly hit shift-right until selecting into the logically first (physically second) group of "abc".  The selection will select these characters:

 ר
bc ר
c ר
 ר
 abc ר

Clearly we're trying to let the arrow keys move the cursor physically rather than logically, but when the shift key is down and thus the selection is being extended, that's impossible, and the result isn't really logically _or_ physically sane.  By comparison Visual Studio (which also puts the words in a LTR reading order) always has the arrow keys move logically, which makes selection updating sane.
(b) Place the cursor at the left edge of the string.  Hit ctrl-right three times.  Now you're at the logical start of the string, which has completely skipped one of the "abc"s.  Now you can repeatedly hit ctrl-left twice, then ctrl-right once, to get back to the same spot.  Whether left and right are physical or logical, we shouldn't be able to move left two words and right one and be at our starting position.
(c) The omnibox maps home/end to logical cursor positions (start/end of string), which is inconsistent with using arrows for physical movement.

->aleventhal who fixed  bug 196326 , which is connected.