Bug 98298 - GTK3: Awful new scrolling behaviour for mouse click in scroll bar (with many pages and comments)
Summary: GTK3: Awful new scrolling behaviour for mouse click in scroll bar (with many ...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.1.0.3 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: GTK3
  Show dependency treegraph
 
Reported: 2016-03-01 07:53 UTC by Luke Kendall
Modified: 2016-10-20 04:16 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
works fine for me with the 700+ file format specification (1.08 MB, video/webm)
2016-03-17 15:21 UTC, Caolán McNamara
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kendall 2016-03-01 07:53:51 UTC
I noticed a new feature which I'm hoping might be something in Gnome3 that I can turn off in LO: as of the upgrade from 5.0.3.2 to 5.1.0.3, if I click in the scroll bar, instead of paging forward (if I click below the scroll-thumb) or back one page (if I click above it), it now painfully pages forward, redrawing each page, until it reaches the point that I'd reach if I dragged the scroll-thumb to that point.

I made the mistake of doing this in a 400-page document with many comments (i.e., interactivity is very laggy and slow anyway), a distance of about 200 pages forward.  Not only did this single mouse click lock up all LO windows while the next 10 mins passed as it struggled to the new point in the document, but it interacted awfully with the desktop: I couldn't click to focus on any desktop item; the most I could do was use Alt-tab to bring different windows to focus.

If you must jump to the scroll position, rather than scroll by 1 page as LO used to, at a mouse click, please, I beg you, don't do it incrementally one page at a time with a redraw for each.  It's torture!
Comment 1 Luke Kendall 2016-03-01 08:01:16 UTC
Oh, I also realised it makes an important interaction ability impossible now: previously, you could select a long range of text, and then click in the scrollbar to view back to the beginning or to the end, as you wished.  (You can't do so by using Page-Up or Page-Down keys, as that loses the current selection and shifts the insertion point.)

And with the new behaviour of clicking in the scrollbar, it's impossible to easily move to the start or the end of the selection, in a long document: it's too imprecise for accurate positioning, and thus too hit-or-miss.
Comment 2 Buovjaga 2016-03-17 12:08:20 UTC
As you mentioned Gnome3, are you running LibO with GTK3?
Launch methods for gtk2 and 3:
SAL_USE_VCLPLUGIN=gtk soffice
SAL_USE_VCLPLUGIN=gtk3 soffice
Comment 3 Luke Kendall 2016-03-17 12:37:56 UTC
Sorry, I can no longer reproduce the problem after I uninstalled libreoffice-gtk3 to get rid of the low-usability Open dialog it brought to LO. I understand that that change was due to Gnome3, not LO (and there's another workaround, too: to select the use of LO dialogs rather than let the desktop environment provide them: good!)

I believe it was at that point that the awful scrolling behaviour ended, but I'm sorry, I can't be sure.
Comment 4 Buovjaga 2016-03-17 14:43:58 UTC
GTK3 + LibreOffice is still experimental and should not be enabled by default.
Another scrollbar bug is bug 98726
Comment 5 Caolán McNamara 2016-03-17 15:21:21 UTC
Created attachment 123662 [details]
works fine for me with the 700+ file format specification
Comment 6 Caolán McNamara 2016-10-18 14:47:58 UTC
Double checked in a 5-2 and no sign of this problem. Maybe it was a temporary period while gtk3 was experimental where there was some smooth scrolling bodge in place.
Comment 7 Luke Kendall 2016-10-20 04:16:36 UTC
I've not had it happen again for months, so I'm perfectly happy for this to be resolved.