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.
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).
(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.
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.
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.
Created attachment 189646 [details] [diff] [review] Better NSScrollWheel handling Includes cleanup. The only thing better than this would be an nsMouseScrollEvent capable of carrying both axes.