Chrome Version       : 60.0.3112.7
OS Version: OS X 10.12.5

So... I'm trying to track down some odd behaviour.

Consider the text "סיבית – ויקיפדיה". This is the title of the Wikipedia page at https://he.wikipedia.org/wiki/%D7%A1%D7%99%D7%91%D7%99%D7%AA 

16 characters. RTHB currently breaks at 6, 7, 8 and 16. That's from the right, so the runs are:

"סיבית "
"–"
" "
"ויקיפדיה"

This causes the first run to have a mix of ascii and non-ascii glyphs. On Mac, there is no fallback from a system UI font that has all those glyphs. The result is icky (see attached mixed.png)

Basically, putting a space *after* RTL text does not break. But putting a space *before* RTL text does break.

I don't think this is a unicode/bidi thing. The same thing happens with Japanese.

E.g. " ありがと" breaks the run after the first character and renders fine. But "ありがと " has no breaks and struggles. Note these are ascii spaces, not full-width (?) spaces. (Typing a space in Japanese IME doesn't cause the same problems).

Starting to trace... I think the problem is some code in RTHB's

int ScriptInterval(const base::string16& text,
                   size_t start,
                   size_t length,
                   UScriptCode* script)

specifically

  while (char_iterator.Advance()) {
    // Special handling to merge white space into the previous run.
    if (u_isUWhiteSpace(char_iterator.get()))
      continue;

Removing that special handling seems to make these problems go away. Runs of whitespace are still merged, but only if they are runs of whitespace in the same script. Do we need that special handling for anything? (Can I kill it?)
 

Deleted: mixed.png 23.7 KB

	mixed.png 23.7 KB View Download