242799 - synaptics touchpad scroll function stopped working 2 days ago

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Clay Campbell]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040505
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040505

I use the nightly_builds and generally have great luck with them.
The last 2 nightly_builds have rendered my emachines synaptics touchpad scroll
functionality useless.  Not a biggy, but I use it all the time and sucks to have
to resort to the arrow keys.

Thanks for all your hard work, as my Dad says "Mozilla Forever!"

-Clay

Reproducible: Always
Steps to Reproduce:
1.  view any webpage
2.  make sure focus is in the main window
3.  touchpad scroll functionality doesn't work at all



Expected Results:  
it should have scrolled, it always has worked in the nightly builds before 2
days ago

Comment 1

[R.K.Aa.]

*** Bug 242986 has been marked as a duplicate of this bug. ***

Comment 2

[R.K.Aa.]

Also happens on an IBM Thinkpad with a Trackpoint device
Still OK in 20040404. Broken in 2004050708

Comment 3

[Urban A. Haas]

Can someone update the status to CONFIRMED? 

Comment 4

[Erin Dalzell]

Doesn't work for me either on a Compaq (HP) Evo N800C running XP and a nightly
from the 10th.

Comment 5

[Christian Merkle]

The last working Mozilla _Firefox_ version is 20040503. In 20040504 and newer,
the scrolling with my Syaptics Unit isn´t working anymore.

There´s a similar bug in Mozilla _Thunderbird_ : 20040504 is working perfectly.
In 20040505 and newer, the scrolling with my Syaptics Unit isn´t working anymore.


System: WinXP Pro SP1, IBM Thinkpad R40 2722-3GG

Comment 6

[timeless]

aaronl: i'm betting this is yours.

Comment 7

[timeless]

aaronl: this is yours. i'm probably going to back you out. please consult with 
all the input device vendors.

Comment 8

[timeless]

aaronl: this is yours. i'm probably going to back you out. please consult with 
all the input device vendors.

Comment 9

[timeless]

i blame ie for the duplicate. submit.

note that you broke the touchpad scroll regions on both my laptop (dell 
latitude c810) and my keyboard (micro innovations). so if i wanted scrolling, 
i'd have to use a mouse and incur more damage to my hands.

they both happen to be synaptics.

given the choice between asking all mozilla laptop users to get new drivers for 
their touchpads, or coming up with an alternate solution for a product that is 
not yet available and which needs changes in order to work anyway, i think the 
choice should be clear.

Comment 10

[Aaron Leventhal]

Can you wait until we talk on IRC before you back it out?

Comment 11

[Ray Trent]

If needed, I'm happy to try to figure out why this stopped working. It would be
helpful, in that case, if someone could tell me what Synaptics driver version
they are using that is having the problem (naturally, I'm somewhat reluctant to
upgrade my machine to a version of Firefox that doesn't scroll for me, but
everyone has to make sacrifices :-). 

I agree with comment 9, though, that having all Mozilla users upgrade their
drivers isn't a desirable solution for a lot of reasons if it's avoidable.

FYI, our current driver's scrolling mechanism looks for windows with a window
class of "MozillaWindowClass" to determine how Moz should be scrolled. If that
changed, that would be a likely source of the problem. Before mid-July 2002, it
was searching for "*Mozilla*" in the window title, but that stopped working in
some situations. 

Re: Comment 2, while I'm not trying to avoid blame per se, IBM TrackPoints not
working hints against it being a problem solely with our driver (that's not a
guarantee, though, our driver is on at least 1 IBM with both a pointing stick
and TouchPad, so without further information it's hard to tell...). However, IBM
uses similar context-sensitive scrolling mechanisms, so it could have the same
root cause.

Comment 12

[Clay Campbell]

driver: synaptics  1/9/2003  7.2.10.0

my machine runs these apps for touchpad control

SynTPLpr.exe and SynTPEnh.exe

This is the latest driver available for my device from emachines, however, I
think synaptics has more recent drivers available.  Like you guys are saying,
having people update to a driver not recommended by the hardware vendor isn't an
option.

Comment 13

[Christian Merkle]

(In reply to comment #11)
> If needed, I'm happy to try to figure out why this stopped working. It would be
> helpful, in that case, if someone could tell me what Synaptics driver version
> they are using that is having the problem (naturally, I'm somewhat reluctant to
> upgrade my machine to a version of Firefox that doesn't scroll for me, but
> everyone has to make sacrifices :-).

I tried v7.5.17.8 and v7.8.10.0 without success. 

 

Comment 14

[timeless]

*** Bug 242745 has been marked as a duplicate of this bug. ***

Comment 15

[timeless]

v7.8.10.0

Ray Trent: see bug 241993, aaronl changed the windowclass.

that's bad. it's why this broke and it's why i assigned the bug to him.

Comment 16

[timeless]

to be clear: i expect aaronl to revert the change, i'm not going to ask a bunch
of big mouse driver vendors to rev their code and an even larger number of end
users to grab the new versions. it took me 4 months to grab a driver for my
laptop; many people never upgrade. the change was made in an effort to help a
product which isn't available yet, so the right thing to do is come up with a
better plan. 

Comment 17

[Urban A. Haas]

The IBM Thinkpad having the problem is just a stick, no touchpad. This is not
just a synaptics issue.

Comment 18

[Aaron Leventhal]

I will take care of this, but not until after the weekend.

I expect to find a way to make the screen readers and the pointer devices happy.

Comment 19

[R.K.Aa.]

can the changes in bug 241993 have caused weirdness in select dropdown boxes?
See http://bugzilla.mozilla.org/show_bug.cgi?id=242560#c7

Comment 20

[Aaron Leventhal]

Bug 242560 is unrelated to this -- that one happens on Linux. This is a
Windows-only bug caused by by Windows-only change.

Comment 21

[Ray Trent]

FWIW, in order to allow more flexibility in this eventually, I'm considering
changing our Mozilla detection code for future drivers to look for "*Mozilla*"
in the window class rather than "MozillaWindowClass". Does this seem like a good
idea? (i.e. would that cause any weird behavior with old versions that don't
understand wheelmouse messages, and would anyone care if it did)

Comment 22

[Aaron Leventhal]

I don't think it would cause weird behavior, and it might be a good idea -- but
it won't really fix this problem for us since we can't make all of our users
upgrade to the new driver.

Comment 23

[Aaron Leventhal]

Ray, it seems like the Synaptics driver checks the windowclass of the last
focus. If the last focused window is MozillaWindowClass and the pointer is
within the bounds of the last focused window and the user initiates scrolling,
then the driver looks up the chain of parent windows to see which one has a
scroll bar. Not sure how it determines when there is a scrollbar or uses them.
Can you comment?

Meanwhile, a screen reader also checks the windowclass of the last focus, and
bases behavior on the window class of the last focus.

So there's a conflict:
* the screen reader wants the window class of the last focus to be different
depending on how it should behave (differently in content vs. UI). 
* the touchpad, mouseheel and pointer stick drivers' scrolling features want the
class to always be MozillaWindowClass.

Since the pointer drivers were there first, and they vastly outnumber screen
reader users, it seems like they win.

I can think of one hack, which is to use the special window classes for screen
readers only when a screen reader is present. I think this is a possibility,
because screen reader users are not going to be using touchpad scrolling. The
difficult is to detect when a screenreader is loaded after Mozilla is launched,
and then change all the window clases. I don't think all screen readers
broadcast across all windows that the SPI_GETSCREENREADER system setting has
changed when it does.

So, we're probably back to asking the screen reader vendors to use control id
again :(

Comment 24

[Ray Trent]

The assessment in comment 23 is essentially correct. In the case of Mozilla,
rather than search for the scrollbars (which has proved tricky for a number of
reasons), we just send wheelmouse messages to the top level window (at least for
modern OS's where that's the spec) whenever the focus window is
MozillaWindowClass. Even that description is something of a simplification, but
it's the general flavor. 

Comment 25

[Aaron Leventhal]

(In reply to comment #24)
> that description is something of a simplification, but it's the general flavor. 

If it's not asking too much, can you provide the full explanation? Is it up to
Mozilla to decide which decendent off the top level window to scroll, based on
the coordinates of the mouse pointer?

Comment 26

[Ray Trent]

Re: comment 25, it's a good thing you asked. My memory was backwards. It was
obsolete OS's that required sending the wheelmouse message to the foreground
window and left the decision up to the app based on pointer position. On
98+/NT4+, we send the message to the window we want to scroll (an app, of
course, is still free to ignore that and scroll whatever window it wants,
include the one under the pointer).

The decision about what window we want to scroll is (again) complicated, because
in some cases we have to deal with non-scrollable widget windows inside
scrollable windows, among other things. We also support 2 scrolling modes: by
default we scroll the focus window (and for wheel-scrolled apps we rely on the
app to forward this to a parent window if needed), but there's an option to
scroll the window under the pointer (subject to similar constraints). It's quite
a bit beyond the scope of a bug comment (not to mention somewhat trade secret)
to try to describe that whole process, but that's close enough to work with for
purposes of this bug. 

It gets even more complicated for apps other than Mozilla, which at least has
the courtesy to respond sensibly to wheelmouse messages, mostly (though I wish
Mozilla properly handled smaller-than-normal wheelmouse messages so I could turn
on our "smooth scrolling" flag... it's so much nicer than line-at-a-time
scrolling). 

Comment 27

[Urban A. Haas]

Is there any way to fix the left/right scrolling on the IBM Thinkpad? Mozilla is
the only app that up/down works, but not left/right. All others, left/right work
fine.

Could this bug be related? Can they all be fixed at the same time?

Comment 28

[timeless]

that is not at all related, this is a specific regression. search elsewhere.

Comment 29

[William Smith]

Our screen reader needs to find an HWND (this is all under Windows 9x/XP/2000) 
to start its traversal of the MSAA accessibility tree.   We search for that 
HWND via a textual configuration script that can look at module names, class 
names, the results of GetWindowLong( GWL_ID ) and other kinds of 
information.   In addition, in the MSAA tree traversal module we also need to 
verify that the window is a Mozilla window vs. a window belonging to other 
applications that have MSAA trees that work differently such as IE and Acrobat.

Before the change under discussion, we would look for an ancestor with a 
controlID with the 0 bit set to 1 and window class MozillaWindowClass/module 
GKWIDGET.    This was working in a fairly old version of Mozilla but now too 
many windows match that pattern.   The result was that we would try to treat 
dialogs as if they were web pages which wasn't useable for our users.

The solution we came up that is under discussion here with was to give windows 
that we should start at (and thus use the function AccessibleObjectfromWindow 
on) the window class MozillaContentWindowClass and windows that were from 
dialogs to use a different window class (MozillaUIWindowClass).   Windows that 
were in the HWND tree that were neutral would still have a class of 
MozillaWindowClass.   There's another new window class, 
MozillaHiddenWindowClass, but I'm not sure I can explain when it's used.

We need to have an unambiguous way of knowing that a given window is allowed 
to accessed via its MSAA tree (web page mode) vs. used as a dialog.   Before 
the current changes to window classes, we weren't able to identify this 
distinction any more because too many windows had a control ID of 1.   When we 
find that HWND we perform the MSAA function AccesibleObjectFromWindow() and 
scan the tree from there.

With the configuration script, we do a combination of matching the controlID 
with a masked constant and searching from the focused window to its ancestors 
looking for a specific window class/module.   We start the search knowing the 
focus HWND and the current active HWND.

The big concern for me is to be able come up with a solution that will be 
stable and won't be inadvertantly broken in future versions of Mozilla.

Comment 30

[Aaron Leventhal]

Did the mousescrolling work in HTML drop down comboboxes (like Target Milestone
on this page) before? I can't get that to work.

Comment 31

[Aaron Leventhal]

Attachment: Change which windows use MozillaContentWindowClass and MozillaUIWindowClass

The client area windows that get focus are now always neutral, with
MozillaWindowClass as they always were. The parent of the client window is now
MozillaContentWindowClass, MozillaUIWindowClass, or #32770 (for dialogs). In
essence, this makes more sense anyway. The top window for content or UI now
describes whether it is content or UI, instead of the child of that window.

This fixes the trackpad scrolling problem and makes it possible for us continue
with the same methodology for gaining Window-Eyes screen reader compatibility.

Comment 32

[Ere Maijala (slow)]

Comment on attachment 148871 [details] [diff] [review]
Change which windows use MozillaContentWindowClass and MozillaUIWindowClass

> -        WCHAR className[19];
> +        WCHAR className[40];
>          nsToolkit::mGetClassName((HWND)wParam, className, 19);

Buffer size changed, but the size parameter to mGetClassName not. A mistake?
Same thing later in that file.

> +  rv = CreateViewAndWidget(itemType == nsIDocShellTreeItem::typeChrome? 
> +                                       eContentTypeUI: eContentTypeContent);

A nit: I'd prefer spaces also before ? and : and I believe that's the prevalent
style too.

Comment 33

[Aaron Leventhal]

Attachment: New patch based on ere's comments. Also added warning comment to be careful when changing window class names.

Comment 34

[Ere Maijala (slow)]

Comment on attachment 148883 [details] [diff] [review]
New patch based on ere's comments. Also added warning comment to be careful when changing window class names.

r=ere

Comment 35

[Aaron Leventhal]

Checking in content/base/src/nsDocumentViewer.cpp;
/cvsroot/mozilla/content/base/src/nsDocumentViewer.cpp,v  <--  nsDocumentViewer.cpp
new revision: 1.374; previous revision: 1.373
done
Checking in layout/html/document/src/nsFrameFrame.cpp;
/cvsroot/mozilla/layout/html/document/src/nsFrameFrame.cpp,v  <--  nsFrameFrame.cpp
new revision: 3.253; previous revision: 3.252
done
Checking in layout/xul/base/src/nsMenuPopupFrame.cpp;
/cvsroot/mozilla/layout/xul/base/src/nsMenuPopupFrame.cpp,v  <-- 
nsMenuPopupFrame.cpp
new revision: 1.228; previous revision: 1.227
done
Checking in widget/src/windows/nsWindow.h;
/cvsroot/mozilla/widget/src/windows/nsWindow.h,v  <--  nsWindow.h
new revision: 3.176; previous revision: 3.175
done
Checking in widget/src/windows/nsWindow.cpp;
/cvsroot/mozilla/widget/src/windows/nsWindow.cpp,v  <--  nsWindow.cpp
new revision: 3.503; previous revision: 3.502
done
Checking in xpfe/appshell/src/nsAppShellService.cpp;
/cvsroot/mozilla/xpfe/appshell/src/nsAppShellService.cpp,v  <-- 
nsAppShellService.cpp
new revision: 1.215; previous revision: 1.214
done

Comment 36

[Aaron Leventhal]

Note that HTML comboboxes don't scroll with touchpad scrolling, but that didn't
work before either. Also, someone pointed out that horizontal scrolling doesn't
work.

Comment 37

[Michael Lefevre]

*** Bug 244197 has been marked as a duplicate of this bug. ***

Comment 38

[Clay Campbell]

Yes!!!  I can verticle scroll, oh sweet God in heaven I can verticle scroll!!!

Thanks guys.

C

Comment 39

[Marciano Siniscalchi]

Sorry to rain on the parade, but the touchpad is stil br0ken on WinXp / Firefox
0.9.1. Sorry if this is something you already knew.

M

Comment 40

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Sorry. I mistook operation.