Open Bug 350594 Opened 18 years ago Updated 2 years ago

Horizscroll should be negated for RTL locales

Categories

(Core :: Layout: Text and Fonts, enhancement)

1.8 Branch
x86
Linux
enhancement

Tracking

()

People

(Reporter: zwnj, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: intl, rtl)

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.
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: fx20-he
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: fx20-he
Severity: normal → enhancement
Target Milestone: mozilla1.8.1 → ---
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl
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!
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.