Closed Bug 594977 Opened 13 years ago Closed 13 years ago

Scrolling with trackpoint/touchpad (Thinkpad, Synaptics drivers) won't work

Categories

(Core :: Widget: Win32, defect)

Product:
Core
Component:
Widget: Win32
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- final+

People

(Reporter: huemob, Assigned: roc)

References

Details

(Keywords: regression)

Attachments

(3 files)

Part 1: refactor hack-detection logic to allow live pref updates
20.59 KB, patch
jimm
: review+
Details | Diff | Splinter Review
Part 2: don't use the FAKESCROLLBAR hack for Synaptics drivers >= 15.x.x
2.87 KB, patch
jimm
: review+
Details | Diff | Splinter Review
Part 3: rejigger the Trackpoint hack for older versions of the Synaptics drivers
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).
I think this might be a regression due to Bug 130078.
Keywords: regression
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.
Status: UNCONFIRMED → NEW
Depends on: 591874
Ever confirmed: true
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.
Blocks: 130078
No longer depends on: 591874
4.0b6 has just installed and the bug is still there.

Back to Chrome again till the next drop...
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+
If I comment out the Firefox line in TP4scrol.dat, vertical and horizontal scrolling work. Sigh.
(In that case we get WM_MOUSEWHEEL messages as expected.) If only these people would stop messing with us.
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.
ALPS touchpads also don't work - neither horizontal nor vertical.
(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.
Strange, because it didn't for the person in comment #3.
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.
Alright, I'll try what I said in comment #17 then.
My drivers version is 13.2.3 and setting hack doesn't do anything, if that helps.
Ivan, do you see this bug?
Yes
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.
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.
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?
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?
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.
I'd like that information for ui.trackpoing_hack.enabled set to 0 AND set to 1.
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...
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)
(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?
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.
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)
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.
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)!
I think we need one bug per driver.
Blocks: 605357
Spun off bug 605354 for ALPS.
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.
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 :-(.
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)
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)
Whiteboard: [needs review]
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 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+
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? :-)
I'll go with InitInputHackDefaults unless someone says otherwise.
Whiteboard: [needs review] → [needs landing]
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!
Whiteboard: [needs landing]
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.
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.
What exactly doesn't work? middle-button+trackpoint scrolling works for me with that driver.
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
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.
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.
(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.
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.
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.
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.
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)
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
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).
Probably. Let's not care about that.
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+
Whiteboard: [just the Part 3 patch needs checkin]
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: 13 years ago
Resolution: --- → FIXED
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.)
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!
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.
Depends on: 622410
(In reply to comment #40)
> Spun off bug 605354 for ALPS.

that is bug 605357
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.
David, can you file a separate bug for this and CC me?
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.
David, actually perhaps you can just comment in bug 622410 with those details.  Thanks!
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
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.