Apache OpenOffice (AOO) Bugzilla – Issue 14570
Scroll wheel gets stuck on forms
Last modified: 2017-05-20 11:29:46 UTC
A writer form of several pages (no db form, just text form with multiline form controls) cannot be fully scrolled using the mouse wheel. Scrolling stops at an undefined point, and you have to click somewhere in the form to get scrolling back. This does not affect pgup/dn, only the mousewheel gets stuck.
correcting sub component (see http://www.openoffice.org/issues/describecomponents.cgi?component=database%20access) assigning to QA
Dietrich, could you attach a sample document to show this? From a quick test, I could not reproduce this - which may be due to the fact that your bug description is rather ... sparse :) this time, and keeps some questions open ...
Sure. Use the sample form attached to issue 14571 and try to scroll through it using the scroll wheel.
confirming changing QA component/component to Writer - this pretty much looks like a Writer core problem targeting to 2.0 assigning to responsible (hopefully :) developer fs->fme: if I was wrong with my guess that this is yours, I apologize - please re-assign in this case :)
Created attachment 6542 [details] sample doc to reproduce the bug case
attached the document from issue 14571 here, for easier handling
FME->MT: There are a couple of multi line edit controls in this document. Seems like they do not pass the scroll wheel event.
Sure they don't pass them back, because MultiLineEdits support them. Same behaviour when mouse is over DD-List-Box. I think from the view of the controls it's correct. Maybe they shouldn't consume the events when they don't perform an action, because there is nothing more to scroll, but that would mean in the case of the dd-List-Box, that they perform some actions before stopping consuming the event, and I don't think that this is what the user wants, so maybe we need a solution to prevent any controls in a document from receiving scroll events...
Do you think it possible to support scrollwheels inside multiline edits, grids and dropdown listboxes without catching the focus? Why is it impossible not to catch the focus while the page scrolls by?
The controls don't catch the focus, VCL sends scroll wheel commands to the window under the mouse pointer, regardless whether it has the focus or not. May be this is the solution: Give the Window a flag not to receive scroll wheel events when not focused. SSA, what do you think? If VCL offers that, this should IMHO become the default behavior for all VCL controls, not only for forms. IMHO the current bahavior make only sense for documents, so maybe these kind of windows should set a flag for GETSCROLLWHEELEVENTSWITHOUTFOCUS.
Sorry, I don't think that this is a good idea. If I understand you correctly, then this means that I always have to focus a control before I can use the scroll wheel on it. I think this is very inconvenient. I suppose there is a reason why Logitec chose to implement exactly the "scroll the window which is nearest to the mouse pointer, regeardless of the focus" behaviour for the mouse drivers, and I suppose it's called usability :). (for Logitec, this in fact is a driver feature, which can be switched on (or off?) with "Use MS office compatible scroll behaviour only", or so) Also Mozilla, which also does have an own toolkit for the form controls in their browser, does not require the focus for wheel events to be handled. Instead I think that the approach suggested first is the better one: Do not consume wheel events when they're not handled. Isn't this a general idea for event handling, anyway? The disadvantage described for the list box wouldn't be too bad, IMO. Not to mention that exactly this listbox behaviour can be observed in Mozilla Browser, too, so we would have at least one product which we are consistent with :).
another remark: If the scroll wheel would always affect the focused window, then this will confuse users: It means that you point to one item on your desktop (or whereever), and scroll, and a control/window in a completely different corner is affected. I think this would be pretty strange, as people tend to associate the mouse pointer location with the location where a mouse action happens. (it would be strange if your mouse click does _not_ affect the window you're pointing at, wouldn't it? :) OTOH, if we say that controls/windows on which the user scrolls (means: s/he points to it and scrolls) do _not_ scroll when not focused, but completely absorb the scroll event, then we have the original situation of this bug. If we say that such controls do not scroll, and not absorb the event, then we have the problem I mentioned above that you always need to focus for scrolling. From a usability perspective, and IMHO of course :), I think the most negliable glitch is the list box which first scrolls their content, and then the surrounding document.
After discussing this with MT again, the following solution seems to be feasible: VCL will support a flag that lets windows ignore scroll events when they are currently not focussed. This flag is by default off, which means nothing will change. The only controls that will have this flag changed are the form controls that are instantiated through the toolkit and thus are easily detectable. This solution would ease scrolling through documents but would not change the whole UI scrolling experience (eg, for dialog or toolbar controls).
this is no crash, thus removing dependency to issue 21786
SBA: Target set to "OOo later".
SSA: reassign to HDU
Accepting this heritage...
Reset assigne to the default "issues@openoffice.apache.org".