Closed
Bug 1083833
Opened 10 years ago
Closed 6 years ago
Firefox RTL - Hook Indicator is not displayed in URL Bar
Categories
(Firefox :: Address Bar, defect)
Firefox
Address Bar
Tracking
()
RESOLVED
INACTIVE
People
(Reporter: mvocom, Unassigned)
References
Details
(Keywords: regression, reproducible, rtl)
Attachments
(3 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
image/png
|
Details | |
(deleted),
image/png
|
Details |
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.
Comment 1•10 years ago
|
||
I'm not sure what you mean by "Hook Indicator". Can you attach a screenshot? [bugday-20141020]
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
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?
Blocks: 997921
Flags: needinfo?(roc)
Flags: needinfo?(mvocom)
Flags: needinfo?(alexhenrie24)
Keywords: regression,
regressionwindow-wanted
I probably broke it when I refactored nsCaret. Simon, can you look into this?
Flags: needinfo?(smontagu)
Flags: needinfo?(roc)
Flags: needinfo?(mvocom)
Flags: needinfo?(alexhenrie24)
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.
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?
Flags: needinfo?(smontagu)
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).
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?
Flags: needinfo?(mvocom)
Updated•10 years ago
|
Version: 33 Branch → 25 Branch
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).
Flags: needinfo?(mvocom)
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).
Comment 11•10 years ago
|
||
Comment 12•10 years ago
|
||
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.
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/
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).
Reporter | ||
Comment 16•10 years ago
|
||
Sorry, it's not Comment 16. https://bugzilla.mozilla.org/show_bug.cgi?id=979653#c15
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.
Component: Untriaged → Location Bar
OS: Windows 7 → All
Hardware: x86 → All
Version: 25 Branch → 29 Branch
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.
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... :/
Updated•8 years ago
|
OS: All → Unspecified
Hardware: All → Unspecified
Version: 29 Branch → unspecified
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.
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.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
You need to log in
before you can comment on or make changes to this bug.
Description
•