Closed
Bug 594977
Opened 15 years ago
Closed 14 years ago
Scrolling with trackpoint/touchpad (Thinkpad, Synaptics drivers) won't work
Categories
(Core :: Widget: Win32, defect)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: huemob, Assigned: roc)
References
Details
(Keywords: regression)
Attachments
(3 files)
20.59 KB,
patch
|
jimm
:
review+
|
Details | Diff | Splinter Review |
2.87 KB,
patch
|
jimm
:
review+
|
Details | Diff | Splinter Review |
5.08 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0b6pre) Gecko/20100909 Firefox/4.0b6pre SeaMonkey/2.1b1pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b6pre) Gecko/20100909 Firefox/4.0b6pre SeaMonkey/2.1b1pre
Vertical scrolling with the touchpad or trackpoint on a Lenovo Thinkpad doesn't work. Works with Seamonkey build 20100826, broken since 20100829 (currently using latest Seamonkey nightly 20100909, still broken).
Strangely enough, horizontal scrolling works fine.
Synaptics driver version (SynTPEnh.exe) is 15.0.24.0 (03Jun10).
Reproducible: Always
Steps to Reproduce:
1. Press middle trackpoint button and move trackpoint up or down
1. (Alternatively, scroll by moving a finger up and down on the right side of the touchpad)
Actual Results:
Window contents do not scroll.
Still worked with build 20100826.
Expected Results:
Window contents should scroll
Worked with Seamonkey build 20100826.
Didn't work since build 20100829.
Synaptics driver version (SynTPEnh.exe) is 15.0.24.0 (03Jun10).
Comment 2•15 years ago
|
||
There was a problem a while ago (bug 589529), but it's supposed to have been fixed at the end of august.
Changing the ui.trackpoint_hack.enabled setting to 0 or 1 doesn't solve the problem either.
Updated•15 years ago
|
Comment 4•15 years ago
|
||
Was working fine with FF 4b4 but has broken with 4b5
Going over to Chrome till this is fixed :-(
Can somebody test a build between Bug 137008 and Bug 589529 to see which one caused this?
Oh, 9/29 is after 137008 but before 589529.
Comment 7•15 years ago
|
||
4.0b6 has just installed and the bug is still there.
Back to Chrome again till the next drop...
Assignee | ||
Comment 8•15 years ago
|
||
I can reproduce this. Strangely, horizontal scrolling works but vertical scrolling doesn't.
We get WM_HSCROLL messages to the main HWND but no messages at all when moving vertically. On my system, we get no messages at all to the FAKETRACKPOINTSCROLLBAR.
I have SynTPEnh.exe version 15.0.18 (22 Apr 10).
Assignee: nobody → roc
blocking2.0: --- → final+
Assignee | ||
Comment 9•15 years ago
|
||
If I comment out the Firefox line in TP4scrol.dat, vertical and horizontal scrolling work. Sigh.
Assignee | ||
Comment 10•15 years ago
|
||
(In that case we get WM_MOUSEWHEEL messages as expected.) If only these people would stop messing with us.
Assignee | ||
Comment 11•15 years ago
|
||
Hmm, it seems to me that setting ui.trackpoing_hack.enabled to 0 in about:config fixes the problem for me. Can anyone else confirm that?
Perhaps the newer drivers do the right thing? If only we could be so lucky.
Comment 13•15 years ago
|
||
ALPS touchpads also don't work - neither horizontal nor vertical.
Comment 15•15 years ago
|
||
(In reply to comment #11)
> Hmm, it seems to me that setting ui.trackpoing_hack.enabled to 0 in
> about:config fixes the problem for me. Can anyone else confirm that?
Yes, now it works ok.
Assignee | ||
Comment 16•15 years ago
|
||
Strange, because it didn't for the person in comment #3.
Assignee | ||
Comment 17•15 years ago
|
||
Anyway, it appears we should do something dependent on driver version here. Turning off hacks is always good.
In bug 592173, 14.0.18 drivers needed the hack. 15.0.18 drivers don't need it, for me. Any other data?
On my machine, HKEY_LOCAL_MACHINE\\Software\\Synaptics\\SynTP\\Install\\DriverVersion is 15.0.18. Maybe we could read that key and if it's there, only enable the hack for drivers < 15.0.0?
heumob, can you confirm that setting ui.trackpoint_hack.enabled to 0 doesn't fix it for you? You need to restart Firefox for it to take effect.
(In reply to comment #8)
> I can reproduce this. Strangely, horizontal scrolling works but vertical
> scrolling doesn't.
>
> We get WM_HSCROLL messages to the main HWND but no messages at all when moving
> vertically. On my system, we get no messages at all to the
> FAKETRACKPOINTSCROLLBAR.
>
> I have SynTPEnh.exe version 15.0.18 (22 Apr 10).
The changelog for the W500 drivers:
<15.0.24.0>
- (New) Added support for installation under the following policy.
(Detect application installations and prompt for elevation : Disabled)
[Local Computer Policy]-[Computer Configuration]-[Windows Settings]-
[Security Setting]-[Local Policies]-[Security Options User Account
Control] : Disabled
<15.0.18.0>
- (New) Added "Scrolling Region Filtering" and "Gesture Filtering".
- (New) Enabled Edge Tap Filtering, Scrolling Region and Gesture Filtering by
default.
<14.0.18.0>
- (New) Support for ThinkPad T410s Switchable Graphics models.
Presumably those changes to the defaults are responsible.
Assignee | ||
Comment 19•15 years ago
|
||
Alright, I'll try what I said in comment #17 then.
Comment 20•15 years ago
|
||
My drivers version is 13.2.3 and setting hack doesn't do anything, if that helps.
Assignee | ||
Comment 21•15 years ago
|
||
Ivan, do you see this bug?
Comment 22•15 years ago
|
||
Yes
Assignee | ||
Comment 23•15 years ago
|
||
Hmm, but Kyle doesn't see this bug with version 14.0.something, right?
I have a completely different driver that's on version 4.
Comment 25•15 years ago
|
||
I'm using a ThinkPad UltraNav (Synaptics driver 11.1.21), and setting ui.trackpoing_hack.enabled to 0 doesn't work for me. The default config worked until a few months ago, I guess (I'm not really using it).
The behavior of the trackpoint when used as a scroller (middle button + red nipple) is changed slightly if you set the hack (icon doesn't disappear when you touch the nipple), although it still doesn't work.
Assignee | ||
Comment 26•15 years ago
|
||
OK. I still think we should sunset the hack for Synaptic drivers > 14.0.
Anyone know if I could install an older driver without screwing up my laptop?
Comment 27•15 years ago
|
||
I have no idea, but I saw in my Windows update that I can update to newer version of Synaptics drivers. Do you have some usefulness of my machine with old drivers for bug testing, or otherwise I would update?
Assignee | ||
Comment 28•15 years ago
|
||
Please don't update yet!
If you have Spy++ or Winspector Spy (http://www.windows-spy.com/, although that seems to be done right now), I would like to know what messages (if any) are sent to the MozillaWindowClass window and its SCROLLBAR child window when you try to scroll vertically using the trackpoint.
Assignee | ||
Comment 29•15 years ago
|
||
You can get Winspector Spy from here: http://www.softpedia.com/get/Security/Security-Related/Winspector.shtml
Assignee | ||
Comment 30•15 years ago
|
||
I'd like that information for ui.trackpoing_hack.enabled set to 0 AND set to 1.
Comment 31•15 years ago
|
||
I can see the link, but it takes me to download link:
http://www.windows-spy.com/files/Winspector_setupU.exe
and I can't get anything from there...
Assignee | ||
Comment 32•15 years ago
|
||
Comment 33•15 years ago
|
||
I hope I've got it right.
So with default setting MozillaWindowClass gets some messages (mousemove, setcursor), and scrollbar gets no messages. But as far as I understand you wanted 2 other cases.
With hack set to 0, I don't see any messages, actually I don't even see Scrollbar as a child class.
With hack set to 1, I don't see any messages, thought there is some Scrollbar class (FAKETRACKPOINTSCROLLBAR)
Assignee | ||
Comment 34•15 years ago
|
||
(In reply to comment #33)
> So with default setting MozillaWindowClass gets some messages (mousemove,
> setcursor), and scrollbar gets no messages. But as far as I understand you
> wanted 2 other cases.
>
> With hack set to 0, I don't see any messages, actually I don't even see
> Scrollbar as a child class.
>
> With hack set to 1, I don't see any messages, thought there is some Scrollbar
> class (FAKETRACKPOINTSCROLLBAR)
1 should behave the same as the default.
So when it's there, the FAKETRACKPOINTSCROLLBAR doesn't get any messages?
Comment 35•15 years ago
|
||
Considering FAKETRACKPOINTSCROLLBAR it is behaving the same, there are no messages in both cases.
MozillaWindowClass has some difference between default and 1, as there are some messages with default value.
Reporter | ||
Comment 36•15 years ago
|
||
Sorry for the late reply, but setting ui.trackpoint_hack.enabled to 0 or 1 doesn't change anything.
Also, commenting out the Firefox line in TP4Scrol.dat, as was suggested earlier, doesn't help either.
(n.b. I'm using Seamonkey, but this shouldn't matter as it's a Gecko problem)
Assignee | ||
Comment 37•15 years ago
|
||
Can you try a nightly build from August 28? I wonder how much of this is due to 130078 and how much is a regression from bug 589529.
Comment 38•15 years ago
|
||
With all the work going into fixing Synaptics support; will ALPS users also ever see a fix? We are suffering from the same issue (no scrolling at all, and back/forward also doesn't work anymore)!
Assignee | ||
Comment 39•15 years ago
|
||
I think we need one bug per driver.
Comment 40•15 years ago
|
||
Spun off bug 605354 for ALPS.
Comment 41•15 years ago
|
||
Well, writing this from Mozilla/5.0 (Windows NT 6.1; rv:2.0b5pre) Gecko/20100828 Firefox/4.0b5pre
So, scrolling still doesn't work with default hack value, and FAKETRACKPOINTSCROLLBAR receives no messages.
With hack 0 the same, only I don't see FAKETRACKPOINTSCROLLBAR class
Finally with 1 value, same as with default.
Assignee | ||
Comment 42•15 years ago
|
||
I think we should add a pref to flip the root window class to MozillaUIWindowClass, but if that doesn't work I'm not sure what we'll do :-(.
Assignee | ||
Comment 43•15 years ago
|
||
This creeped a bit more than I wanted it to, but I want to make ui.trackpoint_hack.enabled live for new windows, and I also want a pref (which I've named ui.window_class_override) to override the main window class, also live for new windows. This should make it a bit easier for people to test combinations of hacks on their own hardware. So I've restructured the code a bit to store just the defaults in global variables, and always consult the prefs every time we open a new window. Seems to work pretty well. Of course, there is the possibility that drivers cache information on a per-process basis or something, so that restarting Firefox will be needed anyway, but whatever.
Attachment #486484 -
Flags: review?(jmathies)
Assignee | ||
Comment 44•15 years ago
|
||
This fixes trackpoint scrolling for me. I realize that it doesn't for people with older drivers, we'll need to deal with that in a separate patch.
Attachment #486488 -
Flags: review?(jmathies)
Assignee | ||
Updated•15 years ago
|
Whiteboard: [needs review]
![]() |
||
Comment 45•14 years ago
|
||
Comment on attachment 486484 [details] [diff] [review]
Part 1: refactor hack-detection logic to allow live pref updates
>+// Default value for Trackpoint hack (used when the pref is set to -1).
>+PRBool nsWindow::sDefaultTrackPointHack = PR_FALSE;
>+ sDefaultTrackPointHack = false;
>+ for (unsigned i = 0; i < NS_ARRAY_LENGTH(wstrKeys); i++) {
>+ HKEY hKey;
>+ long lResult = ::RegOpenKeyExW(HKEY_CURRENT_USER, (LPCWSTR)&wstrKeys[i],
>+ 0, KEY_READ, &hKey);
>+ ::RegCloseKey(hKey);
>+ if (lResult == ERROR_SUCCESS) {
>+ // If we detected a registry key belonging to a TrackPoint driver
>+ // Turn on the hack by default
>+ sDefaultTrackPointHack = true;
>+ break;
>+ }
>+ }
I'm not sure what the current guidelines are (the style guide doesn't mention the use of true/false yet) but since this is a PRBool and we initialized this to PR_FALSE, we should stick with the PR* types here.
>-void nsWindow::InitTrackPointHack()
>+void nsWindow::InitHackDefaults()
How about 'InitTrackPointDefaults' instead?
Attachment #486484 -
Flags: review?(jmathies) → review+
![]() |
||
Comment 46•14 years ago
|
||
Comment on attachment 486488 [details] [diff] [review]
Part 2: don't use the FAKESCROLLBAR hack for Synaptics drivers >= 15.x.x
Same thing here with sDefaultTrackPointHack.
Attachment #486488 -
Flags: review?(jmathies) → review+
Assignee | ||
Comment 47•14 years ago
|
||
These aren't just Trackpoints, they're trackpads and other crazy hardware. I also think the word Hack should be in the name since that's what they are :-). How about InitInputHackDefaults? :-)
Assignee | ||
Comment 48•14 years ago
|
||
I'll go with InitInputHackDefaults unless someone says otherwise.
Whiteboard: [needs review] → [needs landing]
Assignee | ||
Comment 49•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/75ca0ab361b8
http://hg.mozilla.org/mozilla-central/rev/33652dc3d274
OK. Now I need people to download tomorrow's nightly and report in with their driver versions and what's working. It would be especially useful to know if setting ui.window_class_override to MozillaUIWindowClass (and/or enabling/disabling ui.trackpoint_hack.enabled) fixes problems. Thanks!
Assignee | ||
Updated•14 years ago
|
Whiteboard: [needs landing]
Assignee | ||
Comment 50•14 years ago
|
||
There was also a bustage fix:
http://hg.mozilla.org/mozilla-central/rev/0f92c4e81cf3
Comment 51•14 years ago
|
||
If this is it: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101109 Firefox/4.0b8pre
then it seems not to working for me in all combinations I have tried, and I think I tried them all
Synaptics 13.2.3 as said before.
Reporter | ||
Comment 52•14 years ago
|
||
Doesn't seem to work here either (ui.trackpoint_hack.enabled and/or ui.window_class_override as suggested).
Synaptics driver version is still 15.0.24.0.
Assignee | ||
Comment 53•14 years ago
|
||
What exactly doesn't work? middle-button+trackpoint scrolling works for me with that driver.
Reporter | ||
Comment 54•14 years ago
|
||
Doesn't work for me. (Middle-button + trackpoint and/or touchpad scrolling)
Configuration:
- Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b8pre) Gecko/20101119 Firefox/4.0b8pre SeaMonkey/2.1b2pre
- Synaptics driver 15.0.24 03Jun10
What I tried:
- Commenting/Uncommenting the firefox line in TP4scrol.dat as suggested in comment #9
- Setting ui.trackpoint_hack.enabled to -1 or 0
- Setting ui.window_class_override to MozillaUIWindowClass
and hopefully all 8 combinations thereof. If it works for you, I might be doing something very wrong, though. Any ideas what I could try next?
Component: Widget: Win32 → Widget: Qt
Component: Widget: Qt → Widget: Win32
Assignee | ||
Comment 55•14 years ago
|
||
Did you try restarting between attempts?
If you change Tp4scorl.dat I think you need to kill off the Tp*.exe processes and restart them.
Comment 56•14 years ago
|
||
Just checked this on my ThinkPad T60 booted into WinXP. Both touchbad-scrolling and middle-button+trackpoint scrolling are broken, and none of the workarounds posted so far work for me. (with restarts in between)
Version info:
Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101123 Firefox/4.0b8pre
Synaptics Driver 11.1.21.0 (7/3/2008)
* I've set ui.trackpoint_hack.enabled to 0
* I've added the pref "ui.window_class_override" set to "MozillaUIWindowsClass"
* There's actually no mention of "Firefox" in my TP4scrol.dat file, so that workaround was a non-starter.
roc, ping me on IRC if you're around later & have more things that I can investigate here.
Comment 57•14 years ago
|
||
(In reply to comment #56)
>"MozillaUIWindowsClass"
oops, that should be "WindowClass" there.
(That change still doesn't fix this for me, though).
I also tried ui.trackpoint_hack.enabled=1 (with MozillaUIWindowClass set simultaneously), and that didn't fix it.
Comment 58•14 years ago
|
||
A few notes from some more testing I did yesterday:
- From a few targeted local builds, I confirmed that the first bad changeset for both types of scrolling (trackpad & middlebutton+trackpoint) is the last part of bug 130078:
http://hg.mozilla.org/mozilla-central/rev/7804b5cf4313
(probably not a big surprise)
- In a working build (e.g. the changeset immediately before that one), if I make any change to the string in this line...
> 218 const char kClassNameGeneral[] = "MozillaWindowClass";
http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsWindowDefs.h?mark=218-218#207
...then middlebutton+trackpoint scrolling breaks (but touchpad scrolling still works). I can change all the other class names and nothing breaks, though.
Comment 59•14 years ago
|
||
I am not quite sure whether it will help, but just to note that scrolling works on pdf documents in Adobe reader plugin, and not on html documents.
Comment 61•14 years ago
|
||
Aha -- the synaptics executable, syntpenh.exe, contains the string "MozillaWindowClass" (according to both grep & 'strings'). That and "Mozilla" are the only moz-related strings it contains. (No mention of e.g. "firefox" or other window class names.)
That seems to explain Comment 58 -- why middlebutton+trackpoint scrolling breaks when I change that specific string in an otherwise-working Firefox build.
Assignee | ||
Comment 62•14 years ago
|
||
joy joy
Comment 65•14 years ago
|
||
Here is a patch that makes vertical and horizontal scrolling with the
Trackpoint work on this machine, which has v11 of the Synaptics driver.
After tracing through the driver, I found that the reason that the events
are no longer dispatched is that it is expecting there to be a parent of the
window that the mouse pointer is over. There are some comments in the
patch about how the fake windows would work (this is the simplest I was
able to make it).
The patch also fixes a problem with the auto-detection for whether to
enable the hack.
Incidentally, I think the reason that only horizontal scrolling was working
(with the v15 drivers?) was that the fake scrollbar added was a horizontal
one. With the change in HWND structure, it was taking a different path in
its heuristics, and dispatching WM_HSCROLLs accordingly.
Note that even with Firefox 3.6 and the v11 driver, only vertical scrolling
was working. This patch lets scrolling in both directions work. It's kinda
weird in that now WM_MOUSEWHEEL is sent for vertical scrolling but
WM_HSCROLL for horizontal scrolling, but at least it works.
(I tried messing with the Tp4scrol.dat file so that it would match Firefox's
new HWND structure, but to no avail.)
There's a try-server build here, in case anyone afflicted by the problem
wants to try it out to see if it works for them (if and before it lands
on trunk):
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/cmccormack@mozilla.com-a18310e0e585/try-w32-dbg/
Attachment #500003 -
Flags: review?(roc)
Updated•14 years ago
|
Attachment #500003 -
Attachment description: Part 3: rejigger the Trackpoint hack for older versions of the Synaptics drivers a=blocker → Part 3: rejigger the Trackpoint hack for older versions of the Synaptics drivers
Assignee | ||
Comment 66•14 years ago
|
||
You are a hero!
Comment 67•14 years ago
|
||
There is one issue still remaining, which may or may not be worth looking into: when you press down the middle button, before before you start moving the nipple, the mouse cursor changes to one that indicates it will be scrolling. As soon as you start scrolling, though, the cursor changes back to the regular one. I suspect (but haven't checked) that this is to do with Firefox ensuring that the cursor is the right one for the element which now lies underneath the cursor (e.g. changing to a hand when a link moved under the cursor).
Assignee | ||
Comment 68•14 years ago
|
||
Probably. Let's not care about that.
Assignee | ||
Comment 69•14 years ago
|
||
Comment on attachment 500003 [details] [diff] [review]
Part 3: rejigger the Trackpoint hack for older versions of the Synaptics drivers
Looks great!
I mean, it looks nasty, but under the circumstances, thanks a ton!
Attachment #500003 -
Flags: review?(roc) → review+
Updated•14 years ago
|
Keywords: checkin-needed
Updated•14 years ago
|
Whiteboard: [just the Part 3 patch needs checkin]
Comment 70•14 years ago
|
||
Landed part 3
http://hg.mozilla.org/mozilla-central/rev/77143138cfba
I'll leave setting the status of this bug to someone who knows what the situation is.
Keywords: checkin-needed
Whiteboard: [just the Part 3 patch needs checkin]
Lets take remaining issues to followups.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment 72•14 years ago
|
||
Wait, this should work in Mozilla/5.0 (Windows NT 6.1; rv:2.0b9pre) Gecko/20110101 Firefox/4.0b9pre?
It doesn't. It is not fixed!
(Actually, when I first tried scroll in that build it seemed that scrollbar has moved down, but after that it just doesn't work. Could be that I have just touched space accidentally, I don't know.)
Assignee | ||
Comment 74•14 years ago
|
||
Ivan, please file a new bug. And repeat the steps like you did in comment #33, and put the results in the new bug. Thanks!
Comment 75•14 years ago
|
||
OK, it is bug 622410 now.
Interesting thing is that I found that scrolling briefly works when Firefox is starting and is busy and doesn't respond to commands immediately.
Comment 76•14 years ago
|
||
Comment 77•14 years ago
|
||
When scrolling with synaptics 15.1.12 (either one or two finger gestures) in firefox beta 10, the synaptics helper locks up, starts consuming an entire core's worth of CPU power, and the cursor freezes in place until the helper application is forcefully killed. The problem is unique to Firefox 4 Beta 10, all other browsers and applications work fine.
I'm not sure if this is related to the fixes which have been done here, this is a new problem I've only encountered after upgrading to beta 10 from 3.6.
Comment 78•14 years ago
|
||
David, can you file a separate bug for this and CC me?
Comment 79•14 years ago
|
||
Cameron,
I found that the bug was present on 3.6, still couldn't replicate it in any other application but Firefox.
I downgraded to synaptics 14.0.19 which solved the problem. The original 15.1.12 is actually an older version, however the latest 15.x.x was completely nonfunctional. Synaptics drivers are junk... If you still want me to file the bug report I will.
Comment 80•14 years ago
|
||
David, actually perhaps you can just comment in bug 622410 with those details. Thanks!
Comment 81•14 years ago
|
||
Well, just upgraded from 3.6 to 4 RC and i'm not able to Scroll with my Trackpoint (SL300, Alps 7.2.1623.307) in any direction.
Windows 7 32Bit
Comment 82•14 years ago
|
||
I think, I'm going to refer to bug 622410.
If anybody got an idea, pls reply.
Is there a bug for Alps Trackpoints?
(In reply to comment #82)
> I think, I'm going to refer to bug 622410.
> If anybody got an idea, pls reply.
>
> Is there a bug for Alps Trackpoints?
Bug 605357
You need to log in
before you can comment on or make changes to this bug.
Description
•