MouseWheelUp + MouseWheelDown non-local captures bypass Hotkeys and cannot be disabled/reassigned
#VLC on freenode have suggested that this is an "anomaly bug" and a "usability bug" and recommended that I make this report. It's a "pulling hair out" bug for me. ;-)
VLC 0.9.2 Grishenko (Qt4) on Windows Vista captures MouseWheelUp and MouseWheelDown events behind the scenes and assigns them dynamically to the Volume or Track Position sliders, outside of control by the Tools->Preferences->Hotkeys panel. Regardless of any settings in Hotkeys, those hidden assignments always capture those two events. Because those hidden assignments work in parallel to the explicit user assignments in Hotkeys, the user cannot disable them directly, nor disable them indirectly by assigning the events to other unused functions.
What's more, the mousewheel events are not captured locally to control VLC only when the mouse pointer hovers over the corresponding VLC sliders, or when the pointer lies within the VLC window: instead the sliders are moved even when the mouse is on the opposite side of the screen (!).
This has severe usability problems when using VLC as a helper application in Firefox, for example. When a music link on a web page is clicked and the VLC player is spawned, subsequent use of the mousewheel to scroll the web page fails and instead causes either the VLC Volume or Track Position sliders to move, with hugely exasperating effect. The reason for this is of course because focus has passed unexpectedly to VLC, despite the mouse pointer still hovering over the web page and being used to navigate it. From a usability standpoint, this is a nightmare, made worse by the fact that what happens is dependent on the position of VLC on the screen --- either VLC volume or VLC Track Position might be affected, depending (illogically) on where the mouse happens to be on the webpage versus where VLC spawns on the screen.
A related ticket was opened in the past (#1864 (closed)) but the reported behaviour was misunderstood there. From the ticket, "I think the problem here would be that we do not allow you to configure multiple hotkeys/mousecommands to be bound to one single action yet from the interface". However, that analysis is the opposite of the existing situation, in which multiple binding already occurs: MouseWheelUp and MouseWheelDown events are bound to VolumeUp/Down and TrackPositionForw/Back dynamically: binding them afresh to other VLC functions in the Hotkeys window does not override those hidden captures, which are multiple parallel bindings that cannot be overridden.
It is possible to view this problem in a different light entirely: that it is a bug in the dynamic event capture for those two VLC UI components, because MouseWheelUp/Down events are captured by VLC even when the mouse pointer is not hovering over the respective control sliders. Fixing that issue would eliminate this problem entirely. The current behaviour is unhelpful anyway, since which slider is affected is not deterministic from a user perspective because it depends on the relative positions of the VLC window and mouse pointer on the screen even when they are nowhere near each other. Therefore localizing MouseWheel* captures to the VLC window would seem to be the more useful solution.
However, being able to simply disable capture of these two events instead may be less work, and also would overcome this exasperating behaviour.