Description: Unnecessary scrolling in Math's Element pane Steps to Reproduce: 1. Open Math 2. Select in drop-down list on Element pane any of: Unary/Binary Operators Relations Set Operations Functions Brackets Formats Others A content in those sections is small and you can see it all without any scrolling. There is no a vertical scrollbar there too. 3. Try scroll a content in Element pane using a mouse wheel 4. You'll see an unnecessary scrolling Actual Results: Unnecessary scrolling in Math's Element pane Expected Results: There is no scrolling in Math's Element pane if it's unnecessary Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 62dff2844b0bf1d1bcb8eb4d6db529ef4a31bee4 CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: threaded
Ha, never noticed that. Any of the element panels does receive a scroll bar when LO main window y-height is too short to hold all entries. But the scroll of panels that fully show all their elements (and shows no scroll bar) feels odd. Version: 7.1.0.3 (x64) / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
I'm unable to reproduce it or don't understand. When I scroll on a pane without bar nothing happens. Could it be something related with VCL skia? Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: dfb2841fd8291e2375fc3b5da07b52c108db5954 CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
(In reply to dante19031999 from comment #2) > I'm unable to reproduce it or don't understand. > When I scroll on a pane without bar nothing happens. > > Could it be something related with VCL skia? > > Version: 7.2.0.0.alpha0+ / LibreOffice Community > Build ID: dfb2841fd8291e2375fc3b5da07b52c108db5954 > CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 > Locale: en-US (en_US.UTF-8); UI: en-US > Calc: threaded I was first doing the scroll (element panes with no scrollbar) with a USB mouse's wheel. But checked and it also happens with two-finger scroll on a touchpad. Weird. On Windows 10 Home with HD Graphics 620. But it is not Skia related as it also happens with default GDI only rendering.
> I was first doing the scroll (element panes with no scrollbar) with a USB > mouse's wheel. But checked and it also happens with two-finger scroll on a > touchpad. Weird. > > On Windows 10 Home with HD Graphics 620. But it is not Skia related as it > also happens with default GDI only rendering. I've been checking the ElementsDockingWindow and in particular following mxScroll. At first view everything seems fine. Since I can't reproduce it I need more info to know what I'm looking for. What exactly happens when you scroll? If it's not asking too much, would you upload an screencast ?
Created attachment 169906 [details] screencast of sm elements panels scrolling (In reply to dante19031999 from comment #4) > > Since I can't reproduce it I need more info to know what I'm looking for. > What exactly happens when you scroll? > If it's not asking too much, would you upload an screencast ? attached
I found something looking suspicious. However on gtk the problem doesn't seem to exist and can't check it out. Would someone mind testing this? https://gerrit.libreoffice.org/c/core/+/111241 You don't need to build everything. You would need the windows equivalent off: make xmloff && make vcl && make starmath && instdir/program/soffice --math
If anyone has a chance, alas I can't build/rebuild with Dante's patch...
On pc Debian x86-64 with master sources updated today, I could reproduce this with gen rendering (not with gtk3 rendering I use by default). Dante: I cherry-picked your patch, no better here. I don't understand your comment: " You don't need to build everything. You would need the windows equivalent off: make xmloff && make vcl && make starmath && instdir/program/soffice --math" your gerrit patch only shows some change in starmath, so what's the use of building xmloff and vcl ? Did I miss something? You can give a try with gen rendering by typing in a terminal/console: export SAL_USE_VCLPLUGIN=gen && soffice --math
> I don't understand your comment: Starmath depends on those two. Coming from a non very distant branch, rebuilding those should be enough to reproduce starmath current behavior. I guess this means it doesn't work. The odds where not very great. The only possible gap I could found was what looked like the scroll event handler without checking if it was able to scroll. There's no much more I can do since the new info aims somewhere out of my knowledge (vcl). Some useful information could be extracted from the behavior of writer's right panel. My thoughts: It happens with default UI but not GTK3. Starmath implementation is independent of GUI, it's managed by vcl. That makes me suspect from vcl more than starmath. Checking the right panel and other similar panels may help. If the bug is reproduced with another panel then it's vcl. If not we can not know for sure. Judging in the structure of the ElementsDockingWindow I would say it's SmElementsControl::LayoutOrPaintContents if mxScroll->vadjustment_get_value() could actually return a negative value. There could be two implementations if there was scripting via macros and some virtual dependencies (virtual functions overriding), one for gtk3 (works) and others (not works). see: https://opengrok.libreoffice.org/s?defs=vadjustment_get_value&project=core SalInstanceScrolledWindow & GtkInstanceScrolledWindow My guess would be somewhere a missing sign check. In other words, it doesn't cut at 0 and let you scroll into the negative space. > You can give a try with gen rendering by typing in a terminal/console: > export SAL_USE_VCLPLUGIN=gen && soffice --math This ask me to install more stuff. Stuff which by the way is old (7.0.4), I guess from my system repo. If ∃ UI team I would suggest to ask them about it and maybe moving this to the UI sector.
Caolán McNamara, Armin Le Grand, you figure in this wiki page as the experts on vcl. https://wiki.documentfoundation.org/FindTheExpert I have a suspicion this odd bug could be related to vcl. So if you have time for this, I would like you to judge if the hypothesis exposed on the comment nº9 is possible. Thank you for your time.
(In reply to dante19031999 from comment #9) > > I don't understand your comment: > Starmath depends on those two. Coming from a non very distant branch, > rebuilding those should be enough to reproduce starmath current behavior. ... Ok but if your patch concerns only starmath module, even if I did "make xmloff.clean && make vcl.clean", it wouldn't change anything for these 2.
(Forgot to tell I agree with you about the fact the root cause doesn't seem to be starmath per se but more vcl part since we can't reproduce this with gtk3)
A bibisect pointed to commit 644ebf7823c85973e2724cbfcf403cb63b054bfe Author: Caolán McNamara <caolanm@redhat.com> Date: Tue Jan 28 20:40:15 2020 +0000 weld SmElementsDockingWindow The problem is, that the GtkViewport thinks the GtkDrawingArea is too large. You can very easily see this, if you enable the scrollbar by setting mxScroll->set_vpolicy(VclPolicyType::ALWAYS) at the end of LayoutOrPaintContents. A workaround is to additionally set mxScroll->vadjustment_set_upper(0); and also in the mbVerticalMode branch. A fix should probably do this in set_*policy on NEVER (and restore the old value when changed to something else?). There is also a problem with wheel event mappings. The scroll step for VCL comparing to weld seems to be off - VCL is much too small. But that is an other bug. I'll leave the patching to someone else.
https://gerrit.libreoffice.org/c/core/+/87659
(In reply to V Stuart Foote from comment #14) > https://gerrit.libreoffice.org/c/core/+/87659 So, Caolan, please look at it, it's your regression. Thanks
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/86303d2372b30bf02e28ea2b223f0e0aa7a161a3 tdf#140537 scroll-wheeling shouldn't affect disabled scrollbars It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/411c870ed16c6a27bbd9c762e187783b3b39849e tdf#140537 scroll-wheeling shouldn't affect disabled scrollbars It will be available in 7.1.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.