New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 789350 link

Starred by 4 users

Issue metadata

Status: WontFix
Owner:
Closed: Nov 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug



Sign in to add a comment

[Mac] Views implementation of user menu button appears under stoplight buttons in RTL

Project Member Reported by shrike@chromium.org, Nov 29 2017

Issue description

Chrome Version: 64.0.3279.0
OS: macOS 10.12

What steps will reproduce the problem?
(1) Launch in RTL mode (I have #force-ui-direction, #force-text-direction, and #mac-rtl enabled)

What is the expected result?
The user menu button should appear to the right of the stoplight buttons.

What happens instead?
The user menu button appears beneath the stoplight buttons
 
Screen Shot 2017-11-28 at 4.59.15 PM.png
22.5 KB View Download

Comment 1 by ajha@chromium.org, Nov 29 2017

ewald@: M-64 will be branched tomorrow and will be promoted to Beta in 2 weeks time.Please plan the fix accordingly.

 
Thank you!

Comment 2 by lgrey@chromium.org, Nov 29 2017

Is the views menu shipping by default in 64?

Comment 3 by shrike@chromium.org, Nov 29 2017

Yes, their plan is to ship this in M64.

Comment 4 by lgrey@chromium.org, Nov 29 2017

On second look, the stoplights shouldn't be there in a legit RTL situation (10.12+) Try Cocoa browser/Safari/TextEdit/etc. with either 
-NSForceRightToLeftWritingDirection YES -AppleTextDirection YES

or switching to Arabic/Hebrew and logging in/out of your macOS user.

So I think the larger issue is views stoplight location.

Comment 5 by shrike@chromium.org, Nov 29 2017

Hi lgrey,

Can you explain what you mean? I didn't follow about the stoplights should not be there (shouldn't they in RTL) or what you mean by "So I think the larger issue is views stoplight location".

Comment 6 by lgrey@chromium.org, Nov 30 2017

Sorry, I initially got confused and thought this was MacViews browser. Two issues:

1) For CocoaBrowser, #force-ui-direction, #force-text-direction, and #mac-rtl isn't a good test invocation because there's a bunch of things (stoplight location, natural text direction) that don't get triggered that way. If you launch with 

-NSForceRightToLeftWritingDirection YES -AppleTextDirection YES #force-ui-direction #mac-rtl
(or do the RTL language login dance)

you should see something like the attached screenshot.

2) When I was confused and thought we were talking about MacViews browser, I built it and noticed it doesn't reposition the stoplights to the right with the correct RTL flags (so it looks like your screenshot).
Screen Shot 2017-11-29 at 6.57.53 PM.png
40.5 KB View Download

Comment 7 by shrike@chromium.org, Nov 30 2017

OK, thanks for the explanation (and sorry for the confusion - the RTL stuff is a little mind-bending at times).

So this bug should be closed, correct?

Comment 8 by lgrey@chromium.org, Nov 30 2017

There should probably be a separate bug for MacViews browser (maybe there is?) but I'm sure it won't escape our notice by the time we get there, so agreed.

Comment 9 by shrike@chromium.org, Nov 30 2017

Status: WontFix (was: Assigned)
Cc: msrchandra@chromium.org sdy@chromium.org ranjitkan@chromium.org rbasuvula@chromium.org nyerramilli@chromium.org
 Issue 792403  has been merged into this issue.

Sign in to add a comment