User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b1pre) Gecko/20090922 Firefox/3.5.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090922 Minefield/3.7a1pre ID:20090922042828 Auto scroll stops when mouse wheel is turned. This behavior is different from Firefox3.5.*. In Firefox3.5.*,auto scroll does not stop when mouse wheel is turned. Reproducible: Always Steps to Reproduce: 1.Start Minefield with new profile. 2.Enable autoscroll (default on) 3.start Autoscroll by clicking middle button 4. turn mouse wheel Actual Results: Auto scroll stops Expected Results: Auto scroll should not stop I think that this behavior is not the thing which the developer aimed at. Works: http://hg.mozilla.org/mozilla-central/rev/c99ec9f95c64 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090801 Namoroka/3.6a1pre ID:20090801042759 Broken: http://hg.mozilla.org/mozilla-central/rev/8366e5cc9f57 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090802 Namoroka/3.6a1pre ID:20090802042924 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c99ec9f95c64&tochange=8366e5cc9f57 Candidate regression: Bug 501608 - menu popup sounds are played at showing the autoscrolling popup

In the last few builds I've had AutoScroll not work at all on more then half of the tabs I have open. What happens is I switch to a random tab and click my scroll wheel and I get no response, no AutoScroll icon, nothing! I can't find STR as it appears to be completely random. Others are starting to report this as well: http://forums.mozillazine.org/viewtopic.php?f=23&t=1497265 (towards the bottom) BUILD: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090922 Minefield/3.7a1pre (.NET CLR 3.5.30729) ID:20090922151415 ~B

This issue happens Namoroka also. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b1pre) Gecko/20090922 Namoroka/3.6b1pre ID:20090922051248

To clarify, AutoScroll is completely broken for me in some tabs but works in others after Bug 501608 landed (perhaps a coincidence). AUtoScroll has always worked on all of the sites I had loaded. ~B

My issue is completely different then what Alice is reporting. I believe what she is reporting has always been the case, as it certainly is in TraceMonkey builds that do not have Bug 501608 applied. ~B

I'm not sure whether this is an actual bug or not because we don't have the reference/standard behavior of the auto scrolling. I don't have enough samples for the auto scrolling. Hidemaru which is major Win32 text editor in Japan aborts the auto scrolling by the wheel events. IE8 sometimes aborts it, but sometimes not so. I'm not sure what is the expected behavior on IE8... http://mxr.mozilla.org/mozilla-central/source/layout/xul/base/src/nsXULPopupManager.cpp#215 Looks like we cannot control whether the popup element consumes the wheel event or not in each popup element. So, if we need to fix this bug, we need some interface changes, but I'm not sure whether this is an actual bug or not. Perhaps, if the user turns the wheel, we should respect the action. So, it seems that the aborting the auto scrolling by wheel events is better behavior than the old one. But if some users are hard to click the wheel button without the wheel events, we need to try to fix this bug for the accessibility.

Can't we just base autoscroll on platform specific rules if there are any.. If its a firefox regression, we should figure out the best way to have this feature work.

(In reply to comment #5) > I'm not sure whether this is an actual bug or not because we don't have the > reference/standard behavior of the auto scrolling. I agree completely. As proof of this, bug 213496 is the opposite of this bug :-) We need to define a "right" behavior first.

I'm also experiencing this issue in Firefox 3.6 (on Windows 7 Pro x64). Previously, this did not happen. You should still be able to use the mouse wheel while in autoscroll mode. Why did this change?

Fixed Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=136b3db3e75d&tochange=9b6a73bdb237 Maybe this was fixed by the side effect of Bug597723