The input pointer needs to point the other way in RTL locales.

I'm not sure I understand - the RTL caret indicator should be handled by the platform. Unless by "input pointer" you mean something else?

I mean the big > prompt in the input box (which is implemented as a background image IIRC). It should point to the left in RTL locales.

(In reply to comment #2) > I mean the big > prompt in the input box (which is implemented as a background > image IIRC). It should point to the left in RTL locales. Is that how terminals are handled on Windows and Unix in RTL locales?

(In reply to comment #3) > (In reply to comment #2) > > I mean the big > prompt in the input box (which is implemented as a background > > image IIRC). It should point to the left in RTL locales. > > Is that how terminals are handled on Windows and Unix in RTL locales? Well, right now we have a ">" way over on the left, but text is entered right-to-left, since it's a plain old XUL textbox and inherits the default locale settings. I suppose another solution could be to force the textbox to left-to-right mode.

(In reply to comment #3) ehsan: Is that how any terminals (other than in Firefox) are handled on Windows and Unix in RTL locales?

It would be interesting to know how WebKit Inspector handles RTL for its console.

thinking about this further, the console is for entering JavaScript, not plain text. The "window" object is called window no matter which locale you're in. We do want to do the right and consistent thing here, but I don't think it's clear cut what that is.

(In reply to comment #7) > thinking about this further, the console is for entering JavaScript, not plain > text. The "window" object is called window no matter which locale you're in. > > We do want to do the right and consistent thing here, but I don't think it's > clear cut what that is. I *think* this bug is INVALID as you are never going to manipulate the DOM or write JS in an RTL locale. I assume it will always be english.

(In reply to comment #8) > I *think* this bug is INVALID as you are never going to manipulate the DOM or > write JS in an RTL locale. I assume it will always be english. If that's the case, then we should verify that the input box assumes LTR, even if the user's locale is RTL. Regardless, I think it would be worth investigating how other consoles behave.

if it's just a background image, we should be able to use a -moz-transform to flip the image in rtl environments.

(In reply to comment #8) > (In reply to comment #7) > > thinking about this further, the console is for entering JavaScript, not plain > > text. The "window" object is called window no matter which locale you're in. > > > > We do want to do the right and consistent thing here, but I don't think it's > > clear cut what that is. > > I *think* this bug is INVALID as you are never going to manipulate the DOM or > write JS in an RTL locale. I assume it will always be english. Unless I misunderstand what you're saying, I disagree. I think people in non-RTL locales will want to use the Web Console.

.js-term-input:-moz-locale-dir(rtl) { background: url("chrome://global/skin/icons/commandline.png") 4px 2px, no-repeat; -moz-transform: matrix(-1, 0, 0, 1, 0, 0); }

I think we should really wait for Ehsan to get out of bed and give design input (i.e. answer comment 4), and then discuss technical solutions to get there.

(In reply to comment #11) > Unless I misunderstand what you're saying, I disagree. I think people in > non-RTL locales will want to use the Web Console. Indeed you did misunderstand. I'm asking Ehsan to clarify if any of his Persian terminal (Mac Terminal, Linux Gnome Term, etc) is typed into RTL or LTR

(In reply to comment #14) > (In reply to comment #11) > > > Unless I misunderstand what you're saying, I disagree. I think people in > > non-RTL locales will want to use the Web Console. > > Indeed you did misunderstand. I'm asking Ehsan to clarify if any of his > Persian terminal (Mac Terminal, Linux Gnome Term, etc) is typed into RTL or LTR Well, either way, it's not an invalid bug: if people in RTL locales enter text in consoles from left to right, then we should hammer LTR mode into the text box.

Sorry for the delay here guys. So, the data which goes into this text box is inherently LTR (all DOM object names are in latin alphabet), so what we need to do here is to treat the entire box as LTR (and don't flip the arrow image in RTL mode), similar to how we handle the location bar. Patch forthcoming.

(In reply to comment #17) > Created attachment 490678 [details] [diff] [review] > Patch (v1) So, the direction will always be LTR? Just making sure I understand this.

(In reply to comment #18) > (In reply to comment #17) > > Created attachment 490678 [details] [diff] [review] [details] > > Patch (v1) > > So, the direction will always be LTR? Just making sure I understand this. yessir. Adjusting summary.

Comment on attachment 490678 [details] [diff] [review] Patch (v1) Feeback+, passing to gavin for a real r+

(In reply to comment #18) > (In reply to comment #17) > > Created attachment 490678 [details] [diff] [review] > > Patch (v1) > > So, the direction will always be LTR? Just making sure I understand this. Yes, that is correct.

thanks, ehsan!

Gavin: ping?

Comment on attachment 490678 [details] [diff] [review] Patch (v1) include a semi-colon?

mass change: filter on PRIORITYSETTING

CC-ing after the fact. This is fixed.