Yaron Reporter
	Description • 10 years ago

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141011015303

Steps to reproduce:

Firefox RTL (Hebrew).
Set the input language to English.
Position the cursor at the right side of the URL bar.

See: https://bugzilla.mozilla.org/show_bug.cgi?id=997921


Actual results:

The Hook Indicator is not displayed (not even half as is the case in other text boxes).

It used to work in FF 28.

	vasilicamihasca
	Comment 1 • 10 years ago

I'm not sure what you mean by "Hook Indicator". Can you attach a screenshot?

[bugday-20141020]

	Yaron Reporter
	Comment 2 • 10 years ago

In systems with LTR and RTL languages installed, there's a "hook" at the top of the caret indicating whether the direction is LTR or RTL.

http://s22.postimg.org/6p724t9y5/image.png

See: https://bugzilla.mozilla.org/show_bug.cgi?id=997921

	:Gijs (he/him)
	Comment 3 • 10 years ago

Yaron, to be sure, this worked in 32, right? (that's what bug 997921 implies)

roc, Alex, any idea what happened here?

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 4 • 10 years ago

I probably broke it when I refactored nsCaret.

Simon, can you look into this?

	Yaron Reporter
	Comment 5 • 10 years ago

No, it didn't work in 32 either.
It used to work in 28.

I want the caret to be on the left side of the URL Bar when I start the browser (many RTL users have requested it).

I used to change the following code in omni\chrome\toolkit\res\forms.css:

@-moz-document url-prefix(chrome://) {
  input.uri-element-right-align:-moz-locale-dir(rtl) {
    direction: ltr !important;
    // text-align: right !important;
  }

  Make sure that the location bar's alignment in RTL mode changes according
     to the input box direction if the user switches the text direction using
     cmd_switchTextDirection (which applies a dir attribute to the <input>).
  input.uri-element-right-align[dir=ltr]:-moz-locale-dir(rtl) {
    text-align: left !important;
  }
}

I would comment the line "text-align: right !important;".

Prior to 29, the caret would be on the left and I could move it to right. Also, part of the hook was there.
From FF 29, the caret couldn't be moved to the right.

About a week ago, I changed the aforementioned code to:

@-moz-document url-prefix(chrome://) {
  input.uri-element-right-align{
    direction: ltr !important;
    text-align: left !important;
  }

  input.uri-element-right-align[dir=rtl]{
    text-align: right !important;
  }
}

Now, I can move the caret to the right, but the hook is not displayed.

Anyway, the original code does not seem to achieve its purpose at all.

	Simon Montagu :smontagu
	Comment 6 • 10 years ago

So if I understand correctly, the issue here is that bug 997921 fixed the case where the RTL indicator was concealed outside the left edge of the input field, but not the case where the LTR indicator was concealed outside the right edge. Is that correct?

	Yaron Reporter
	Comment 7 • 10 years ago

That is correct.
The problem is only in the URL Bar.

***
In other input fields (after the fix), only half of the indicator is displayed (1 px instead of 2).

	Alex Henrie
	Comment 8 • 10 years ago

I'm not so sure that this is a regression. I tested various versions of Firefox and found that the bug with the LTR hook is present at least as far back as Firefox 25. The bug affects both HTML and XUL single and multiline textboxes.

Yaron, can you please test with Firefox 25 and tell me whether you can see the LTR hook when the cursor is positioned at the right edge of the textbox?

	Yaron Reporter
	Comment 9 • 10 years ago

Hi Alex,

Thank you for your work on the issue.

FF 24 - FF 28:
In all textboxes, the LTR hook is half displayed when the cursor is positioned at the right edge of the textbox.
The RTL hook is half displayed when the cursor is positioned at the left edge of the textbox.


FF 29 - FF 33:
The same as earlier versions (that is after your patch in bug 997921), except the URL bar:
The LTR hook is NOT displayed at all when the cursor is positioned at the right edge of the textbox.
(This problem does not exist in 24. I'm quite sure it started in 29. If it's important, I'd be glad to check it with 25 - 28).

http://s14.postimg.org/5j2qxjzht/Search_Bar.png
http://s4.postimg.org/v168kwru5/URLBar.png
(Screenshots in 33).

	Alex Henrie
	Comment 10 • 10 years ago

If you could double-check Firefox 25, I'd appreciate it.

I tested Firefox 25 by running `hg update FIREFOX_AURORA_25_BASE` and applying the attach patch to force the LTR indicator to appear. I'll upload some screenshots. I was not able to get Firefox 24 or earlier to compile on my computer. However, if your computer is set up in an RTL locale, you can just download and install an old Firefox binary (you shouldn't need to mess with the source code to force the hook to appear).

	Yaron Reporter
	Comment 13 • 10 years ago

I'm not a pro, and I don't have a compiler installed on my computer.
Could you please upload a setup file? Or is there another way?

Pale Moon 25.02 is based on FF 24.

Thanks again.

	Alex Henrie
	Comment 14 • 10 years ago

Yaron, you can download Firefox 25 for Windows from https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/25.0/win32/

	Yaron Reporter
	Comment 15 • 10 years ago

I knew that. :) I thought you wanted me to test 25 with your patch.

Anyway, there is a difference between 25 and 33 (and probably 29 as well).

In 25:
When you start the browser (or open a new window), the caret is at the right corner and the hook is not displayed.
Pressing Ctrl+Shift+X, however, reveals the hook.
Changing text direction again moves the caret to the left.
Changing text direction now, the caret is moved to the right and the hook (or rather half of it) IS displayed.

This is a bug in itself.
See Comment 16.

In 33:
The hook is never displayed when the caret is at the right corner (i.e. not even after changing text direction twice).

	Yaron Reporter
	Comment 16 • 10 years ago

Sorry, it's not Comment 16.
https://bugzilla.mozilla.org/show_bug.cgi?id=979653#c15

	Alex Henrie
	Comment 17 • 10 years ago

Okay, I was finally able to reproduce your exact issue by installing the Force RTL extension <https://addons.mozilla.org/en-US/firefox/addon/force-rtl/> and editing nsCaret::ComputeCaretRects. The bug is reproducible in both Windows and Linux, and on both x86 and x64. A regression test yielded the following:

The first bad revision is:
changeset:   163981:3475821c2448
user:        Ehsan Akhgari <ehsan.akhgari@gmail.com>
date:        Fri Jan 17 10:31:03 2014 -0500
summary:     Bug 675579 - Part 1: Set the dir attribute on the input/textarea element when switching the text direction; r=roc

So you are correct, this bug first appeared between Firefox 28 and Firefox 29. The bug I mentioned in comment 8 is either a different bug or not a bug at all. And there is still the bug you brought up in comment 15 about having to press Ctrl+Shift+X twice to change the text direction of the address bar the first time.

	Yaron Reporter
	Comment 18 • 10 years ago

Thank you Alex. I appreciate your perseverance.

If anyone is going to fix this, please see also Bug 1095915.

	(no longer active)
	Comment 19 • 10 years ago

That regression range is very surprising.  I tried to come up with a hypothesis that would explain this, but couldn't... :/

	Tomer Cohen :tomer
	Comment 20 • 8 years ago

I can reproduce this on Linux, but only once the caret is at the rightmost location. ItielMaN suggests it might be just cropped, so it could be a theme issue, so 2px padding could be enough to solve it.

	BMO Automation
	Comment 21 • 6 years ago

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.