299949 - Scroll wheel misbehaves when built against 10.4 SDK

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Mark Mentovai]

When Camino is built against a 10.4 SDK (including 10.4.0 and 10.4u):

The scroll wheel, or actually, the whiz-bang two-fingered scrolling PowerBook
trackpad, doesn't work properly.  The scrollbar doesn't move at all initially
when the user attempts to scroll in this manner.  Eventually, after a good deal
of finger movement in vain, the app lazily decides to respond.

Slow movements are more likely to be ignored.

This may be a general problem with Cocoa widgets using these SDKs.

Comment 1

[Wevah (Nate Weaver)]

Another way I've found to get out of some drag-hangs is to initiate another
drag. The OS apparently only keeps track of one drag at a time (which makes sense).

Comment 2

[Wevah (Nate Weaver)]

(In reply to comment #1)
> Another way I've found to get out of some drag-hangs is to initiate another
> drag. The OS apparently only keeps track of one drag at a time (which makes
sense).

Bah; wrong bug. Sorry.

Comment 3

[Mark Mentovai]

Bug-specific synopsis to follow.

http://developer.apple.com/releasenotes/Cocoa/AppKit.html:

NSScrollWheel events (Section added since WWDC)
In order to support finer-grained scrolling required by new devices, the
NSScrollWheel event and the handling of NSScrollWheel events within NSScrollView
has changed. For scrollWheel mice, the delta fields may now contain fractional
components. These fractional values are made available to applications built on
Tiger or later. Applications built on Tiger or later which do their own handling
of the NSScrollWheel event need to be prepared to deal with fractional values,
for example by rounding the scroll amount computed from the event to an integral
value before scrolling. Applications built on Panther or earlier will receive
integral values compatible with the values received on previous releases.

Comment 4

[Mark Mentovai]

Here's the problem.  In nsChildView's scrollWheel:, we're truncating
(float)delta -1 < d < 1 to (int)0, resulting in no scrolling.  The system gives
float deltas, but on apps that target pre-Tiger, the floats contain integral
values, so it was never a problem.  In Tiger-targeted apps, the deltas are
non-integral.  nsMouseScrollEvent's delta field is an int, and the rest of gecko
expects scroll deltas in integral lines.

The easiest solution is to use ceil(delta) and floor(delta) to build integral
values.  I thought I wouldn't like this, but I implemented it and it seems fine
to me.

A more involved solution would save up fractional portions of deltas until
they've exceeded a threshhold (probably 0.5 or 1.0) and fire off adjusted gecko
events as needed.  This sort of stinks, because you still need to wait to
accumulate 1.0 lines of scroll before there's any perceptible motion, the
threshhold would only reduce the wait for the initial scroll.  It's also a pain
to maintain proper state considering that things other than the wheel can adjust
the scroll position.  The more I think about this idea, which I initially
thought would be better, the more I hate it.

So let's not do that.  I think the naïve approach is a winner here.

More to do here: it's possible for a single NSEvent to have both deltaX and
deltaY nonzero.  This situation should result in a pair of gecko events. 
Presently, any vertical motion beats horizontal motion.

Also, the paragraph following the one I quoted in the AppKit change doc says
that under Tiger, regardless of target, we can take NSEvents with both deltaX
and deltaY zero.  I'm experiencing this.  We should handle this condition by not
firing off any gecko events at all.

Patch forthcoming.

Comment 5

[Mark Mentovai]

Attachment: Better NSScrollWheel handling

Includes cleanup.  The only thing better than this would be an
nsMouseScrollEvent capable of carrying both axes.

Comment 6

[Mark Mentovai]

It's in.