I'm not 100% clear on what this is reporting.

The alt+XXX shortcuts are pre-existing.  Are the pre-existing shortcuts wrong?  That is, do we use alt-left for back in RTL UIs today, even though we should be using alt-right?

The separate issue is of how we display the shortcuts in this UI, assuming we get the right shortcuts to begin with.  We need to ensure the image order onscreen as well as the image orientation is correct.

In general, I would seek to avoid hardcoding something like "alt + left" into the UI code.  We already have a mechanism for obtaining the correct localized shortcut labels, which we use in the context menu code ("back" and "forward" are labeled with shortcuts).  We should reuse that code in order to get the set of things to display.

> The alt+XXX shortcuts are pre-existing.  Are the pre-existing shortcuts
> wrong?  That is, do we use alt-left for back in RTL UIs today, even
> though we should be using alt-right?

I wasn't sure how far back the Alt+Left/Right shortcuts have been around, but regardless, they are the way I described (Alt+Left always goes back, even on RTL languages).

> The separate issue is of how we display the shortcuts in this UI,
> assuming we get the right shortcuts to begin with.  We need to ensure
> the image order onscreen as well as the image orientation is correct.

As I said, I will be assuring that the images displayed on screen are correctly matching the keyboard shortcut (which is currently the wrong way around), so at least we give the correct instruction.

> In general, I would seek to avoid hardcoding something like "alt + left"
> into the UI code.  We already have a mechanism for obtaining the correct
> localized shortcut labels, which we use in the context menu code ("back"
> and "forward" are labeled with shortcuts).  We should reuse that code in
> order to get the set of things to display.

Hmm. That makes my life harder for a number of reasons:
1. The menus show the full word "Left Arrow" and "Right Arrow" instead of the arrows "←" and "→" which I think look nicer, are shorter, easier to understand what it's telling you, and have been agreed by UI review.
2. The strings in the menu do not have the correct formatting to parse them into a depiction of a key with a border in the bubble UI.

I would prefer to just have a separate copy of the keyboard shortcut strings for my bubble text. Anyway, that is not what this bug is about; this bug is about the shortcut being actually around the wrong way.

It would be worth checking whether other browsers use alt-left for back or forward in RTL.  I'm curious whether we disagree.

Intuitively, alt-left for back is wrong, as you note.  But it's possible this is one of those cases where the shortcut ends up universally being the same even though it makes no sense.

As for the text, my biggest concern is for internationalized keyboards where perhaps the shortcut is not in fact alt-left, because alt is mapped weirdly (AltGr) or for some other reason.  If we know for sure this is always the right shortcut in every locale/keyboard layout, I'm OK using separate strings and logic.  But you might have to understand the context menu logic to know (at which point it might become obvious how to tweak it to have the same code just give you what you want?).

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue has been moved once and is lower than Pri-1. Removing the milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I'm not sure how to test RTL-mode IE/Firefox.  Without knowing what other browsers here do, I'm too scared to make any changes to Chrome.

This could be reassigned to me to implement if someone else tested and found that Chrome is an outlier here and thus the most plausible behavior (what this bug requests) is indeed what we should be doing instead.

Firefox is easy to test in Linux:
$ LANG=he firefox

I just tested it. It behaves the same as Chrome currently (Alt+Left is back, Alt+Right is forward, the left arrow icon goes forward, the right arrow icon goes backward).

Just using it for a minute is giving me a headache. I still think this behaviour is broken, and it doesn't surprise me that it's broken in other browsers too. I still think we should try and fix it.

I'm more interested in Windows, and in particular IE (and Windows Explorer?) on Windows, since it seems like that's more likely to support RTL users well than any other browser/OS combo.  I don't trust Linux anything :P  (But thank you for testing anyway!)

OK, I tried IE 11 and Edge 25 on Windows 10. Both exhibit the same behaviour as Chrome and Firefox (Left Arrow goes back, Right Arrow goes forward).

Just manually confirmed that the keyboard shortcuts (both in the NewBackShortcutBubble view, and the context menu) *are* correctly displayed in both Arabic and Hebrew (i.e., Back is "Alt+Left Arrow" and Forward is "Alt+Right Arrow"). So we've got that going for us, which is nice.

OK, so I agree our shortcuts are weird, but at least they're consistent with everyone else.

I'd still be willing to change this if we can get agreement from the other vendors to also change it, so we all stay consistent.  I'm worried about this disrupting RTL users who are presumably used to the current mappings, but if those folks also think this is worth doing, then let's go for it.

Do you know any of the right people to contact on the Firefox and IE teams (and I guess we could do Safari while we're at it)?  If not, maybe Marc or Darin or Anthony would have some ideas.

> I'm worried about this disrupting RTL users who are presumably used to the current mappings

On the Chrome side, I'd be surprised, since I'd assume most people were using Backspace up until recently (I didn't know about Alt+Left/Right until the backspace removal happened). I haven't looked at data though.

I don't know who to talk to on other browsers about this but I can contact someone at Mozilla. No idea who to talk to on IE.

I cross-posted this to the Firefox bug tracker:
https://bugzilla.mozilla.org/show_bug.cgi?id=1289285

+CC pawliger -- Marc, do you know how we'd find the right person on the IE team to talk to about this?

Not sure the latest browser contacts. +CC skare for possible contacts

We have consensus from Mozilla:

https://bugzilla.mozilla.org/show_bug.cgi?id=1289285#c6
> Consensus seems to be that this change makes sense. I don't think we should be
> too worried about breaking muscle memory. Doing this might be slightly painful
> for a short time but that seems preferable over keeping nonsensical behavior
> forever.
>
> Please let us know when you've decided to do this and we'll follow suit.

Do you think it's still worth contacting Microsoft or is this sufficient agreement? I'm happy to do it; it would be pretty easy I think.

I think we should get in touch with Microsoft.  If we propose this and tell them we and Mozilla are both on board and would like to make all the changes together, they will probably say yes, and we can all do so.  If we don't contact them, they may not ever notice this change, which just means users lose out.

Hoping to hear from Travis about who the right MS people to talk to might be.

Ping: We didn't hear back about this.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Ping: Peter, we both ignored this for a year. Should we just proceed with the change and contact Mozilla to also make the change?