Bug 109190 - Auto Optimal View gives jarring experience
Summary: Auto Optimal View gives jarring experience
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
5.2 all versions
Hardware: All All
: medium minor
Assignee: Justin L
URL:
Whiteboard: target:6.2.0 target:6.1.0.1
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2017-07-18 12:07 UTC by David
Modified: 2018-07-04 19:11 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
video showing weird jumping view behaviour (1.38 MB, video/x-matroska)
2017-12-23 04:00 UTC, David
Details
myBJJ NZ - Attendance Card 2018.odg: an example document in which jumping behaviour is observed (58.09 KB, application/vnd.oasis.opendocument.graphics)
2017-12-23 04:03 UTC, David
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David 2017-07-18 12:07:08 UTC
This has been a problem for a while and I have refrained from reporting it because I am tired of being flamed by people who insist it isn't a problem or that it is a feature. 

Well, the AI used to move the view to the "optimal" view isn't working well in LO Draw. I am tired of having the page jump to what LO thinks is the optimal view because often I get only the outside edge of my drawing and the rest of the view is completely off the drawing canvas. It is jarring and annoying. Sometimes you can fool the AI by changing the zoom level, otherwise you try to scroll back to the drawing and the same thing happens again and again.

Yes, this might be a feature but it is BROKEN. How about allowing us to disable it altogether. I think I am experienced enough to scroll the window to the position I want.
Comment 1 Buovjaga 2017-08-08 08:44:19 UTC
Please give steps to reproduce the issue.

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the information.
Comment 2 David 2017-12-23 04:00:54 UTC
Created attachment 138604 [details]
video showing weird jumping view behaviour
Comment 3 David 2017-12-23 04:01:56 UTC
After getting flamed in a forum I didn't bother adding more info but this bug still drives me crazy. I only use Draw but I use it daily. The same "optimal view" bug has been present through all of the official releases since I originally reported it. Since that time I have moved to a new laptop and through several versions of xubuntu linux. I've started with clean profiles. The same issue is still present. It is also present in the new version 6.0.0.1 version I tried today.

In the video I have attached I have a document. There are columns of numbers. I want to play around with the font size in the leftmost column while visually comparing it to the next one on the right. I have zoomed in at 280%. I click in the column and CTRL+A to select all of the numbers. Then I just click on a number again to deselect them. Then the view jumps to a completely illogical place. It does it several times. 

This happens in almost every document at some point. It is very random. All I want to do is have a way to turn off / disable the optimal view. I DON'T WANT THE VIEW TO ASSUME IT KNOWS WHAT THE BEST VIEW IS FOR ME.

I've had enough of this weird behaviour so I decided to repost. Surely I am not the only linux user experiencing this. PLEASE do not flame me or tell me this is a feature. It is a BUG. PLEASE don't reply unless you have something MEANINGFUL to contribute. After some of the rude behaviour I've experienced in forums I fire right back.
Comment 4 David 2017-12-23 04:03:06 UTC
Created attachment 138605 [details]
myBJJ NZ - Attendance Card 2018.odg: an example document in which jumping behaviour is observed
Comment 5 Buovjaga 2017-12-23 16:40:59 UTC
(In reply to David from comment #3)
> In the video I have attached I have a document. There are columns of
> numbers. I want to play around with the font size in the leftmost column
> while visually comparing it to the next one on the right. I have zoomed in
> at 280%. I click in the column and CTRL+A to select all of the numbers. Then
> I just click on a number again to deselect them. Then the view jumps to a
> completely illogical place. It does it several times. 

I reproduce the jumping.

You are in luck as it does not happen in 5.0 and the bug can therefore be pinpointed through bisecting.

Arch Linux 64-bit
Version: 6.1.0.0.alpha0+
Build ID: 12d3d90b87d1685d526f576eba62caa79c0df418
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded
Built on December 22nd 2017

Win 10
LibO 5.0.2 and 5.3.0 alpha1
Comment 6 Justin L 2018-05-19 16:16:09 UTC
bisected to LibreOffice 5.2 branch.
2016-03-22	tdf#98646 Fixed freeze by flattening loops	Armin Le Grand
https://cgit.freedesktop.org/libreoffice/core/commit/?id=23391fdb5cffb62006415ad1f4c96b6ed5d50cf8

cc: Armin
Comment 7 Justin L 2018-05-22 17:27:03 UTC
simple workaround: https://gerrit.libreoffice.org/54678
Comment 8 Justin L 2018-06-01 06:05:46 UTC
(In reply to Justin L from comment #6)
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=23391fdb5cffb62006415ad1f4c96b6ed5d50cf8
There is a bug in the conversion from 
while(rRect.Bottom() > aNewPos.Y() + aVisAreaSize.Height())
to
const long distBottom(rRect.Bottom() - aNewPos.Y() - aVisAreaSize.Height());

While the bottom of the object is lower on the page than the visual Top position plus the height of the screen, move the screen down by the size of the object.  The loop could first be finished when the shape bottom is exactly at the bottom of the screen: rRect.Bottom() = aNewPos.Y() + screen Height.
or rRect.Bottom() - (aNewPos.Y() + aVisAreaSize.Height()) = 0
or rRect.Bottom() - aNewPos.Y() - aVisAreaSize.Height() = 0

 https://gerrit.libreoffice.org/55156

Note that this is not exactly perfect for the described case because the screen will move better, but the cursor will not be in the place where the use clicked. It will be in the same place on the screen, but since the contents moved, it won't be on the clicked contents.  (That problem existed already before the regression.)

However, this DOES fix the following jumping problem. Find Sept 30 "Holidays" and position the screen so that you only see "Holi". Arrow right through Holidays. Now it will just scroll slightly, instead of jumping to the opposite side of the screen.
Comment 9 Commit Notification 2018-06-06 18:13:47 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=13328a36d68c4141219d9cc549e6d76e108e6076

tdf#109190 sd MakeVisible: fix flattened loop logic error

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 10 Commit Notification 2018-06-14 04:31:24 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9c18b25f19855709cf4adddeefe4c9765f2f4f4f&h=libreoffice-6-1

tdf#109190 sd MakeVisible: fix flattened loop logic error

It will be available in 6.1.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 Justin L 2018-06-14 04:56:24 UTC
(In reply to David from comment #3)
> I only use Draw but I use it daily.
The fix will be available in the upcoming LibreOffice 6.1 version which will be available around August 12. However, note the caveat in comment #8. Based on that and your frustrations with the feature in general I decided not to backport to 6.0 stable branch. Since you only use Draw, I expect that you will not have any reservations upgrading to a "fresh" version of LO.
Comment 12 Xisco Faulí 2018-06-14 09:53:43 UTC Comment hidden (obsolete)
Comment 13 Xisco Faulí 2018-06-14 09:58:54 UTC Comment hidden (no-value)
Comment 14 Xisco Faulí 2018-06-14 10:02:37 UTC
Verified in

Version: 6.2.0.0.alpha0+
Build ID: 1cf27cb44380f4a2bd6778c2dbbdef2a2a00cbc8
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded
Comment 15 Commit Notification 2018-07-02 07:54:25 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6fffd09833a5bd602b0117f48656afd07fd40f41

tdf#109190 sd: only MakeVisible on mouseclick-up

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 16 Commit Notification 2018-07-03 11:23:49 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e1bab58778fd501f2d2aff7e5dc61eefdc229c9a

tdf#109190 sd: cancel selecting status on new mousedown

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 17 Commit Notification 2018-07-04 19:11:39 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=85ba2c3193d83c84e584ea8c008fdd4019cb8e2b&h=libreoffice-6-1

tdf#109190 sd: only MakeVisible on mouseclick-up

It will be available in 6.1.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.