Description: LO stops scrolling if mouse cursor being above a table cell/ form element (in table) Steps to Reproduce: 1. Open attachment 191601 [details] from bug 158878. 2. Hoover with the mouse above the empty field 'Other information' on page 1 3. Start scrolling with scrollwheel or swiping (nothing happens) 4. Put cursor off-page and start scrolling (fine) Actual Results: Stops scrolling Expected Results: Scrolling Reproducible: Always User Profile Reset: No Additional Info: Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: a9ad36ae46ff76c0d59b0d170314fdd3a9ee5d35 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded
Also in 7.0 and in Version: 5.1.0.0.alpha1+ Build ID: 49c2b9808df8a6b197dec666dfc0cda6321a4306 Threads 4; Ver: Windows 6.29; Render: GL; and in OpenOffice 2.2.0
Reproducible. But I guess if you have the focus on the field, the scroll it's about it, not the document.
I can reproduce it in openSUSE Tumbleweed: Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: 60(Build:1) CPU threads: 16; OS: Linux 6.6; UI render: default; VCL: kf5 (cairo+xcb) Locale: es-ES (es_ES.UTF-8); UI: es-ES Calc: threaded But I don't know if it's a "works as expected" or not.
Even if the Text Box control contains enough lines to overflow its height, the scroll doesn't move the text. So definitely something wrong here. My expectation would be: - if there is no content to scroll inside the text box, scroll the whole page - if there is content to scroll inside the text box, scroll the content A bit like web browsers do. UX/Design team, would you agree? Tested in 6.0.0.3 and recent trunk build: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e83c7ec2f4d801365235bf56d7cc8cf31ef4a00e CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
(In reply to Stéphane Guillou (stragu) from comment #4) > My expectation would be: Scrolling controls inherit the (mouse) events and don't forward in to the parent. => NAB
(In reply to Stéphane Guillou (stragu) from comment #4) > My expectation would be: > - if there is no content to scroll inside the text box, scroll the whole page > - if there is content to scroll inside the text box, scroll the content No strong objections. I'm a bit afraid that users may ask for no scroll events in the dropdowns with date values. Perhaps we distinguish between hover and focus (and scroll the control only when focused, ie. click on the text box, dropdown etc.). The test documents has no scrollbars activated on the text box. And even if the field contains many lines it will not scroll. Different bug.