414960 - Horizontal scroll is backwards

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[zaitcev]

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:
mousewheel.horizscroll.withnokey.action;0
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

Comment 1

[Michael Ventnor]

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.

Comment 2

[Michael Ventnor]

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

[Michael Ventnor]

Attachment: Patch

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 :)

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't understand why having DOWN be the opposite sign from RIGHT can be correct.

Comment 5

[Michael Ventnor]

Attachment: 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.

Comment 6

[Michael Ventnor]

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.

Comment 7

[zaitcev]

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

[zaitcev]

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 9

[Damon Sicore (:damons)]

Comment on attachment 300562 [details] [diff] [review]
Patch 2

a1.9+=damons

Comment 10

[Reed Loden [:reed]]

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
done
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
done

Comment 11

[Sylvain Pasche]

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

[Sylvain Pasche]

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.