MacViews: fix bubble direction in RTL.

ui/views/BUILD.gn

Index: ui/views/BUILD.gn
diff --git a/ui/views/BUILD.gn b/ui/views/BUILD.gn
index bbbb74d4ca9f674676bf6c1e9a8ccc57b44371de..e476c6e7d7fdad7be34db470588bb7fbfdec998c 100644
--- a/ui/views/BUILD.gn
+++ b/ui/views/BUILD.gn
@@ -621,6 +621,12 @@ component("views") {
   }
 
   if (is_mac) {
+    if (mac_views_browser) {

[sky, 2016/11/28 16:22:22]

Why does whether the browser uses views influence the direction?

Assuming that is valid I would prefer not to have files with the names you list
here. Can platform_style.cc and platform_style_mac handled the conditionals?
Does mac_views_browser map to a buildflag? If not, can it?

[tapted, 2016/11/29 06:43:54]

We never implemented proper RTL support for the Cocoa browser window :/. There
is `--enable-features=ExperimentalMacRTL` but it currently just flips the tab
strip and window frame. Flipping the toolbar is a tougher prospect (hopefully we
will switch straight to a toolkit-views browser for that).

So, e.g. for RTL on Mac, the bookmark star, extensions, etc. all remain on the
right, and the padlock remains on the left. This accounts for all the bubbles we
care about right now. (an exception would be the profile switcher - it should
open to the right in RTL, but we haven't ported that to toolkit-views).

This means that if we _do_ flip the bubble direction, the bubble opens towards
the outside of the browser window, rather than towards the inside of the browser
window.
It doesn't currently have a BUILDFLAG. I've added one (Done.).

There are some downsides of that (I've been resisting it for a while..), but
they're no longer as bad as the old #ifdef approach, so I guess I'm sold it it
:).

+      sources += [ "style/platform_style_mac_views_browser.mm" ]
+    } else {
+      sources += [ "style/platform_style_mac_cocoa_browser.mm" ]
+    }
+
     deps += [
       "//ui/accelerated_widget_mac",
       "//ui/events:dom_keycode_converter",