The default bug view has changed. See this FAQ.

Horizscroll should be negated for RTL locales

NEW
Unassigned

Status

()

Core
Layout: Text
--
enhancement
11 years ago
7 years ago

People

(Reporter: zwnj, Unassigned)

Tracking

(Blocks: 1 bug, {intl, rtl})

1.8 Branch
x86
Linux
intl, rtl
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
Values of mousewheel.horizscroll.*.numlines should be negated in RTL locales, as up/down, back/forward, etc are reverse.

Currently, I set them on "fa" firefox-l10n.js, but Pike needs approval for this.
(Reporter)

Comment 1

11 years ago
RTL locales really need it.

IMHO the best way for the branch is to put them on firefox-l10n.js.  Pike, may I put them for fa/Persian?
Blocks: 352116

Comment 2

11 years ago
I'm not convinced. I tried to get this working with my mouse, and I didn't get it to work at all, which may be the fault of my mouse driver.

Given that this is really minor, this doesn't block a release, nor do I want to take changes to firefox-l10n.js without verifying what this does in real life.

I'd need to understand if this is really a locale specific thing (I doubt it right now) or something that depends on RTL on a textinput field, and, even more so, if my guess on that being only relevant in textinput fields is right.

Unsetting milestone, lowering severity. Not going to take that on Firefox 2, likely not code fixes, nor hacks around those.
No longer blocks: 352116
Severity: normal → enhancement
Target Milestone: mozilla1.8.1 → ---
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl

Updated

9 years ago
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: layout.bidi → layout.fonts-and-text
Behnam, can you please provide more information on what kind of problem this produces, and whether or not it's present on trunk/1.9.1?  Thanks!
You need to log in before you can comment on or make changes to this bug.