Bug 140537 - Unnecessary scrolling in Math's Element pane, post weld
Summary: Unnecessary scrolling in Math's Element pane, post weld
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Formula Editor (show other bugs)
Version:
(earliest affected)
7.2.0.0.alpha0+ Master
Hardware: All All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:7.2.0 target:7.1.2
Keywords: bisected, regression
Depends on:
Blocks: Elements-Pane
  Show dependency treegraph
 
Reported: 2021-02-19 14:56 UTC by Roman Kuznetsov
Modified: 2021-03-03 08:13 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
screencast of sm elements panels scrolling (4.22 MB, video/mp4)
2021-02-19 18:13 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Kuznetsov 2021-02-19 14:56:56 UTC
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
Comment 1 V Stuart Foote 2021-02-19 16:25:59 UTC
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
Comment 2 dante19031999 2021-02-19 16:42:33 UTC
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
Comment 3 V Stuart Foote 2021-02-19 17:09:48 UTC
(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.
Comment 4 dante19031999 2021-02-19 17:32:27 UTC
> 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 ?
Comment 5 V Stuart Foote 2021-02-19 18:13:19 UTC
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
Comment 6 dante19031999 2021-02-19 18:45:36 UTC
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
Comment 7 V Stuart Foote 2021-02-19 19:14:12 UTC
If anyone has a chance, alas I can't build/rebuild with Dante's patch...
Comment 8 Julien Nabet 2021-02-19 20:26:43 UTC
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
Comment 9 dante19031999 2021-02-20 00:23:47 UTC
> 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.
Comment 10 dante19031999 2021-02-20 00:29:10 UTC
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.
Comment 11 Julien Nabet 2021-02-20 07:34:56 UTC
(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.
Comment 12 Julien Nabet 2021-02-20 07:53:10 UTC
(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)
Comment 13 Jan-Marek Glogowski 2021-02-20 13:57:35 UTC
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.
Comment 14 V Stuart Foote 2021-02-20 14:19:27 UTC
https://gerrit.libreoffice.org/c/core/+/87659
Comment 15 Roman Kuznetsov 2021-02-20 15:16:33 UTC
(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
Comment 16 Commit Notification 2021-03-01 16:32:14 UTC
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.
Comment 17 Commit Notification 2021-03-03 08:13:24 UTC
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.