Screenshots of WIP are attached.

I'm not sure that the RTL layout is correct... but I can't figure out that the existing RTL layout for autofill suggestions is correct either. It seems that the suggestions are always laid out in the same alignment as LTR.

(WIP CL is at https://codereview.chromium.org/2604273004)

Deleted: Screen Shot 2017-01-05 at 12.02.11 AM.png 33.8 KB

	Screen Shot 2017-01-05 at 12.02.11 AM.png 33.8 KB View Download

Deleted: Screen Shot 2017-01-05 at 12.02.03 AM.png 23.9 KB

	Screen Shot 2017-01-05 at 12.02.03 AM.png 23.9 KB View Download

Deleted: Screen Shot 2017-01-04 at 11.57.39 PM.png 36.5 KB

	Screen Shot 2017-01-04 at 11.57.39 PM.png 36.5 KB View Download

Deleted: Screen Shot 2017-01-04 at 11.57.25 PM.png 26.2 KB

	Screen Shot 2017-01-04 at 11.57.25 PM.png 26.2 KB View Download

Thanks for the screenshots! Vertical alignment of the red and grey labels seems off, is that just me?

Hmm, now that you mention it, I see that too. I wonder why that could be, since the icon and text are vertically aligned just like other autofill suggestions are...

Sorry for the delayed response. I haven't done looking at the latest implementation yet. I'll do so next 2-3 days.

Does the RTL behavior change when the page is RTL?

For this error condition, yes, this is as nonsensical as you suspect; everything should be ordered the other way. For the RTLness of Autofill, I would defer to the judgement of my colleagues who use RTL languages every day to say what they expect.

- c4: Done implementation review in the review doc, left some comments. go/fns-uiir 
- c5: could anyone point me to the layout code with padding and light height values? 
- c7: Will check with someone who knows about RTL layout (next week). If you know anyone, please ask as well. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f05489ec7aa13934819a0ac5363a65d491fa8e82

commit f05489ec7aa13934819a0ac5363a65d491fa8e82
Author: estark <estark@chromium.org>
Date: Sat Jan 07 03:53:35 2017

Style the Form-Not-Secure warning on Mac

This CL fixes the layout/styling of the "Login not secure"/"Payment not secure"
warning in the autofill dropdown on HTTP pages. The fixes are to:
- make the icon/title/subtitle appear in the correct order
- use the correct icons

BUG= 672662 

Review-Url: https://codereview.chromium.org/2604273004
Cr-Commit-Position: refs/heads/master@{#442151}

[modify] https://crrev.com/f05489ec7aa13934819a0ac5363a65d491fa8e82/chrome/browser/ui/cocoa/autofill/autofill_popup_view_cocoa.mm

+pendar for further advice

fix proposal re: c3 and c7 for RTL layout and writing direction

0) If UI language is RTL, apply the followingRTL layout.
1) Within 1st row, the layout order of each element is from right to left, and right-aligned to the row.
2) Within a text element, the writing directionof RTL language is from right to left.
3) 2nd row (Payment not secure/Login not secure) is also translated, written in RTL, and right-aligned to the row.
4) Note: (i) icon is kept as-is while (?) icon is mirrored (not used in this UI).
5) Autofill data in LTR text keeps the writing order in LTR, but the layout order is from right to left, and right-aligned.

Deleted: fns-rtl-layout.png 305 KB

	fns-rtl-layout.png 305 KB View Download

re: c10, correction:
3) 2nd row (*Payment autofill disabled/Login autofilling disabled*) is also translated, written in RTL, and right-aligned to the row.

Thanks Hwi, I'll look at implementing the RTL behavior this week.

Per your question in comment #8:
> - c5: could anyone point me to the layout code with padding and light height values?

Most of the layout constants are in this file:
https://cs.chromium.org/chromium/src/chrome/browser/ui/autofill/autofill_popup_layout_model.h?q=GetRowBounds&sq=package:chromium&l=35

Calculating row bounds is at [1] and drawing the suggestion for Mac at [2]. Is that what you're looking for?

[1] https://cs.chromium.org/chromium/src/chrome/browser/ui/autofill/autofill_popup_layout_model.cc?q=GetRowBounds&sq=package:chromium&l=245
[2] https://cs.chromium.org/chromium/src/chrome/browser/ui/cocoa/autofill/autofill_popup_view_cocoa.mm?sq=package:chromium&l=104

Btw, re: item (3) in comment #10, I suspect that string translations for M57 haven't happened yet which is why the "Payment/Login not secure" message isn't translated. I suspect that once it's translated it will be properly RTL aligned.

It seems the RTL is working, but the RTL layout depends on whether the *page* is RTL, rather than based on the UI language (try the button at the bottom of http://rsolomakhin.github.io/autofill/). Is that undesirable?

Attaching screenshot that Lucas sent me of when he was testing the page in RTL mode

Deleted: 2017-01-13.png 84.3 KB

	2017-01-13.png 84.3 KB View Download

I *believe* there is nothing left to be done. The text and the icon shows up properly in English, Hebrew, and Arabic, regardless of direction.

`ShowAutofillPopup` [1] has an explicit text_direction, which is intentionally set matching the HTML *field* direction for both the "Not Secure" autofill warning [2] and the autocomplete warning [3].

We can easily modify that by replacing the use of the text field direction with:

    base::i18n::IsRTL() ? base::i18n::TextDirection::RIGHT_TO_LEFT : base::i18n::TextDirection::LEFT_TO_RIGHT

We can also hack just the direction of the line for the autocomplete dropdown, but I don't think we should. The existing behaviour is intentional for form fields, and I don't think it should be in scope for Form Not Secure.

[1] https://cs.chromium.org/chromium/src/components/autofill/core/browser/autofill_client.h?type=cs&sq=package:chromium&rcl=1484339010&l=152
[2] https://cs.chromium.org/chromium/src/components/autofill/content/renderer/password_autofill_agent.cc?sq=package:chromium&dr=CSs&rcl=1484339010&l=895
[3] https://cs.chromium.org/chromium/src/components/autofill/content/renderer/password_autofill_agent.cc?sq=package:chromium&dr=CSs&rcl=1484339010&l=1448

Based on comment 17, I was testing RTL wrong, and I think it's working as expected (see screenshot in comment 16). So, marking this as Fixed.