Looks to me like the drag handle area is getting placed on the right edge of the strip instead of the left.

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

Thank You!

It sounds like this is, in fact, a regression in M69.  I don't understand what "non-regression" means in comment 0.

Actually, do we support these flags on Mac?  On a second look it looks like the frame layout code is expecting the traffic lights to have flipped to the opposite corner (which is also where I'd expect them for RTL), but I don't know if that's what Macs would actually do for true-RTL windows.

If we do support these, I suspect at least two things have to happen:
(1) BrowserNonClientFrameViewMac::CaptionButtonsOnLeadingEdge() has to return false in this case; see how GlassBrowserFrameView::CaptionButtonsOnLeadingEdge() keys off base::i18n::IsRTL()
(2) BrowserNonClientFrameViewMac needs to modify the return values of GetTabstripLeftInset() and GetTabstripRightInset() (soon to be converted to GetAfterTabstripItemWidth() in a CL I'm working on) to account for the caption buttons moving

There may be more changes needed to position various frame items correctly in logical order as well.

MacViews triage: over to lgrey@ :)

macOS doesn't flip the traffic lights until you restart or relog with Arabic/Hebrew as the system language. This affects some other issues like natural text direction as well, so I think that switching UI direction in a session is unsupported OS behavior.

I'm going to leave this open but downgrade to P3 since it wouldn't hurt to do what Safari does: detect that we're in this middle state, and lay out everything in RTL but leave space for the traffic lights on the right.

I don't think Chrome supports switching the UI direction without restarting either; I think the bug here is simply that we don't support RTL layout at all.  The plan in comment 6 should implement some of comment 8.

We support it. If you switch to Arabic, then log in and out, the toolbar and traffic lights will all be where you expect (see attached). You can simulate it via 
-NSForceRightToLeftWritingDirection YES -AppleTextDirection YES

when launching via command line.

Deleted: Screen Shot 2018-07-09 at 10.52.05 AM.png 30.5 KB

	Screen Shot 2018-07-09 at 10.52.05 AM.png 30.5 KB View Download

But is that with MacViews on or off?  I would assume that's with it off.

That's MacViews on. We don't have MD refresh in Cocoa :)

Odd.  OK, I don't know how that works in the code then.

Renamed to make this actionable.

For this purpose, "partial" RTL refers to the situation where the conditions for RTL are met, but the system is still putting traffic lights on the left.

"Mass UI Triage" update :
Rechecked the above issue on Mac OS X(10.13.1,10.13.6,10.14.2) using latest Canary build : 72.0.3609.3 and the issue is still reproducible.

@lgrey: Could you please take a look in to this issue.

Thank you..!!

Deleted: Canary_behavior.mov 2.5 MB

	Canary_behavior.mov 2.5 MB View Download

Unassigning, since I don't see myself getting to this P3 in the near future.