Adding RB Label as this is a recent Regression. Please remove if not required.
Thank You.

What's weird specifically?

And what's the expected behavior? In your expected screenshot, I see that the Mac UI is still LTR.

Is Mac supposed to ignore the RTL force UI direction?

With response to comment #2 :

Mac OS should support the RTL force UI direction completely.
The view site info and the url should open from RTL, whereas in Mac the view site info and the url does not changes its direction even if the 'RTL force UI direction' flag is enabled.
In mac the permission bubble opens in LHS of the window, if in maximize mode the bubble is not seen completely.
Please refer the screencast of Mac and Windows OS behavior after enabling the above flag.

Deleted: Mac_behavior.mov 6.4 MB

Mac_behavior.mov 6.4 MB Download

Deleted: Windows_behavior.mp4 881 KB

	Windows_behavior.mp4 881 KB View Download

I see. In that case, I don't think my CL did it. Can we have a per-rev bisect?

Performed per-rev bisect and unable to get bad builds using new script. More over tested this issue on Mac Pro 10.11.6 using chrome #55.0.2841.0 and not able to reproduce this issue.

dmascarenhas@ - Attaching screen-cast for reference, Could you please confirm is this issue still seen on chrome latest versions? 

Deleted: 645405.mp4 1.9 MB

	645405.mp4 1.9 MB View Download

With response to comment #5:

Above issue is still reproducible on Latest Chrome Version: 55.0.2868.0 on Mac Retina (10.11.5)
Please refer the screencast

Note: Pre Condition:1. Enable 'Force UI direction' flag.
                    2. Enable 'Toolkit-Views WebUI-style Browser Dialogs' flag

Correction in Manual bisect info:
Good build:53.0.2748.0
Bad build:53.0.2750.0 ('Toolkit-Views WebUI-style Browser Dialogs' flag is newly added from build no-53.0.2750.0

Deleted: Actual_bubble.mov 6.5 MB

Actual_bubble.mov 6.5 MB Download

====================================

Good Build:

53.0.2748.0   Base Position: 395748


Bad Build:

53.0.2750.0   Base Position: 396337

=====================================

Able to repro this issue on MAC (10.11.6) for the Google Chrome Stable Version - 53.0.2785.116

This is a regression issue broken in M53, below mentioned is the bisect info:

CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/53.0.2748.0..53.0.2750.0?pretty=fuller&n=10000

Suspecting Commit: 5763588fd12942f8829b5c21300ad094bb0e5203			

Review URL: https://codereview.chromium.org/1935993004

@ellyjones: Could you please look into the issue, and if it has nothing to do with your changes and if possible please do assign it to the concerned owner.

Thank you.

Note: Issue is on MAC OS only. 

Mac does not properly support RTL right now. Known deficiency.

I'm untagging this RBS and lowering priority from Pri-1 to Pri-2, since this regression requires the user to manually enable an experimental flag (MacViewsWebUIDialogs).

We have a bunch of individual RTL bugs with Page Info [1].

From what I can tell, #force-ui-direction is an experimental flag and Proj-MacRTL is a corresponding label, and the native Mac Page Info simply ignores it, right?
I've updated the title to reflect that; please comment if I'm missing any other purpose to this bug.

[1] https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component%3AUI%3EBrowser%3EOmnibox%3EPageInfo+RTL&colspec=ID+Pri+M+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=tiles

I believe this is MacViews (not MacRTL).

MacViews Page Info does RTL correctly; this bug is about native Mac.
If MacRTL is not right for this bug, what is MacRTL for?

shrike@: Ping about MacRTL for comment #17.

MacRTL currently belongs to lgrey@, who is out through the end of Feb I think. I'll assign this back to shrike@ for the moment. To be clear, this bug is that the *cocoa* info bubble does not honor force-ui-direction, nor does it support RTL in general.

Probably we should just let Harmony take care of this?