Horizontal scroll is backwards

RESOLVED FIXED in mozilla1.9beta4



11 years ago
11 years ago


(Reporter: zaitcev, Assigned: ventnor.bugzilla)



Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)



11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b3pre) Gecko/2008012508 Fedora/3.0b3pre-0.beta2.12.nightly20080121.fc9 Minefield/3.0b3pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b3pre) Gecko/2008012508 Fedora/3.0b3pre-0.beta2.12.nightly20080121.fc9 Minefield/3.0b3pre

When scrolling with a horizontal strip on Synaptics, the
horizontal scrollbar moves backwards as compared to the
vertical bar or other applications.

Reproducible: Always

Steps to Reproduce:
1. First you must establish that your pointing device works correctly.
   This step ensures that you don't have your buttons remapped inside
   X to suit Firefox

1.1 Open a text file with a 80 character line in gedit (actually
    any app will work, only Firefox is backwards, but let's use gedit)
1.2 Go Preferences->Editor, uncheck "Wrap"
1.3 Return to text. Move horizontal scroller, verify operation.
    For example, on a laptop with Synaptics, moving finger to the
    RIGHT will move the SCROLL TAB to the RIGHT. Compare with the
    operation of the vertical scrollbar, it should be the same.

If you scroll backwards at that point, fix it in your X setup

2. Run Firefox
2.1 Go to about:config, set this:
2.2 Verify that every other mouse setting is at default
2.3 Find something wide, like Red Hat Bugzilla
2.4 Narrow the browser window until horizontal scroll-bar appears
2.5 Scroll it, verify operation
    It's backwards

Actual Results:  
Horizontal scrolling is backwards

Expected Results:  
Horizontal scrolling same as all other GNOME applications
Version: unspecified → Trunk

Comment 1

11 years ago
I can confirm this, and this is a regression from Firefox 2.

I may know where to fix this, the problem is knowing whether or not this will break things. I'll try and attach a patch soon.
Ever confirmed: true

Comment 2

11 years ago
Hmm, this isn't a regression from Firefox 2 since that shows it...
Yet Epiphany with Gecko 1.8 doesn't show the problem.

Comment 3

11 years ago
Created attachment 300499 [details] [diff] [review]

This fixes it for us. AFAIK, this would only break web compat if a page takes the DOMMouseScroll event and implements Firefox-Linux-specific workarounds. But I think it would be advantageous to fix our UI, and if any such web workarounds exist the webmasters can get rid of them.

The GDK constant names are probably misleading :)
Assignee: nobody → ventnor.bugzilla
Attachment #300499 - Flags: superreview?(roc)
Attachment #300499 - Flags: review?(roc)
Component: OS Integration → Widget: Gtk
Product: Firefox → Core
QA Contact: os.integration → gtk
I don't understand why having DOWN be the opposite sign from RIGHT can be correct.

Comment 5

11 years ago
Created attachment 300562 [details] [diff] [review]
Patch 2

Turns out it was due to a Linux hater with an agenda^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H an old assumption about platforms that I never remember being true.
Attachment #300499 - Attachment is obsolete: true
Attachment #300562 - Flags: superreview?(roc)
Attachment #300562 - Flags: review?(roc)
Attachment #300499 - Flags: superreview?(roc)
Attachment #300499 - Flags: review?(roc)
Attachment #300562 - Flags: superreview?(roc)
Attachment #300562 - Flags: superreview+
Attachment #300562 - Flags: review?(roc)
Attachment #300562 - Flags: review+

Comment 6

11 years ago
Comment on attachment 300562 [details] [diff] [review]
Patch 2

Fix a severe and confusing UI deficiency while removing a lot of code at at the same time.
Attachment #300562 - Flags: approval1.9?

Comment 7

11 years ago
Michael, unfortunately it's not easy enough for me to build Firefox.
I have to wait for this to end in builds before I can test it.

Comment 8

11 years ago
I've read the second patch TO THE END, and it dawned on my what an
idiot I was. Replaced the ..numlines of -1 with 1 and the scroll
works now.

I am not so keen on having horizonltal delta fall from 3 to 1,
the speed looks fine as it is now, but since it's configurable
as I realize now, no problem.
Comment on attachment 300562 [details] [diff] [review]
Patch 2

Attachment #300562 - Flags: approval1.9? → approval1.9+
Keywords: checkin-needed
Checking in widget/src/gtk2/nsWindow.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsWindow.cpp,v  <--  nsWindow.cpp
new revision: 1.258; previous revision: 1.257
Checking in modules/libpref/src/init/all.js;
/cvsroot/mozilla/modules/libpref/src/init/all.js,v  <--  all.js
new revision: 3.727; previous revision: 3.726
Last Resolved: 11 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9beta4

Comment 11

11 years ago
So this changes the default preferences from moving back/forward in the history to horizontal scrolling, is it expected?

I came to this bug when noticing my mouse side buttons were no longer acting as back/forward buttons. I tuned the preferences to have the previous behavior, but I'm wondering if this could bring some frustrations to Linux users who discover their side buttons no longer work as before (I'm not sure if my configuration of mapping the side buttons to the horizontal axis is common or not).

Comment 12

11 years ago
well forget that, my configuration isn't representative. I might have changed it from default because I found no other way to use the side buttons as back/forward. But now bug 355477 is looking promising.
You need to log in before you can comment on or make changes to this bug.