Closed
Bug 414960
Opened 17 years ago
Closed 16 years ago
Horizontal scroll is backwards
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.9beta4
People
(Reporter: zaitcev, Assigned: ventnor.bugzilla)
Details
Attachments
(1 file, 1 obsolete file)
4.85 KB,
patch
|
roc
:
review+
roc
:
superreview+
damons
:
approval1.9+
|
Details | Diff | Splinter Review |
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
Updated•17 years ago
|
Version: unspecified → Trunk
Assignee | ||
Comment 1•17 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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 2•17 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.
Assignee | ||
Comment 3•17 years ago
|
||
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
Status: NEW → ASSIGNED
Attachment #300499 -
Flags: superreview?(roc)
Attachment #300499 -
Flags: review?(roc)
Updated•17 years ago
|
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.
Assignee | ||
Comment 5•17 years ago
|
||
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+
Assignee | ||
Comment 6•17 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?
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.
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•16 years ago
|
||
Comment on attachment 300562 [details] [diff] [review] Patch 2 a1.9+=damons
Attachment #300562 -
Flags: approval1.9? → approval1.9+
Updated•16 years ago
|
Keywords: checkin-needed
Comment 10•16 years ago
|
||
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
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9beta4
Comment 11•16 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•16 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.
Description
•