Bug Hunting Session
Bug 105368 - Horizontal line sticks to upper edge of the screen while moved with up/down arrow keys, if the line extends outside the visible page area
Summary: Horizontal line sticks to upper edge of the screen while moved with up/down a...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
5.2.0.4 release
Hardware: x86-64 (AMD64) All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 114373 (view as bug list)
Depends on:
Blocks: Zoom-Issues
  Show dependency treegraph
 
Reported: 2017-01-16 15:02 UTC by ybk
Modified: 2018-06-14 09:52 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Test file (8.38 KB, application/vnd.oasis.opendocument.graphics)
2018-05-19 18:39 UTC, Buovjaga
Details
Screenshot showing the problem (30.02 KB, image/png)
2018-05-27 18:46 UTC, Buovjaga
Details
Screen recording of moving a line in 3.6.7 (61.42 KB, video/x-matroska)
2018-05-31 09:32 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ybk 2017-01-16 15:02:02 UTC
Description:
When the page is zoomed in over %100, selecting a horizontal line with mouse and trying to move with arrow keys from keyboard causes the document to "jump" to the upside of the screen. Pressing the arrow keys moves the line but on the drawing area, line is seen sticked to upper edge of the screen and the document seems to be moving (in any direction). So alignment with arrow keys is not possible in zoomed views. If document zoomed out back to %100 then behaviour is normal.

Steps to Reproduce:
1.Open a new DRAW document
2.Draw a horizontal line and zoom in over %100 
3.Select the line and press any arrow key

Actual Results:  
Line position is sticked to upper side of the screen, when pressing the arrow keys line seem to stop but the document is moving. Line is moving actually in the direction of the arrow key but looks like document is moving. Which makes alignment a pain.

Expected Results:
Document view shall be still and line shall be moving.


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Comment 1 Buovjaga 2017-01-24 10:00:52 UTC
Not reproduced. Please copy & paste the contents of your Help - About.

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the information.

Win 7 Pro 64-bit Version: 5.4.0.0.alpha0+
Build ID: 1c27286b9d5331634c073cd3e327bd941e61bbb6
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2017-01-23_03:24:17
Locale: fi-FI (fi_FI); Calc: group
Comment 2 ybk 2017-01-24 10:35:13 UTC
Sürüm: 5.2.3.3
İnşa №: d54a8868f08a7b39642414cf2c8ef2f228f780cf
İşlemci Görevleri: 4; İşletim Sistemi Sürümü: Windows 6.2; UI Gerçekleyici: varsayılan; 
Yerel: tr-TR (tr_TR); Calc: group

Additional comment: I tried to reproduce and realised that line shall be zoomed in until it does not fit in the screen.
Comment 3 ybk 2017-01-24 10:35:55 UTC Comment hidden (obsolete)
Comment 4 Buovjaga 2017-01-24 11:03:04 UTC
Ah, now I can reproduce. Now I did not go full screen and I zoomed so the line went outside the visible area.
The line travels at the top of the screen area while I press down.
Comment 5 Regina Henschel 2017-12-10 22:47:42 UTC
The bug has been introduced between Version: 5.2.0.0.alpha0+ and Version: 5.1.6.1, see duplicate bug 114373.
Comment 6 Regina Henschel 2017-12-10 22:48:11 UTC
*** Bug 114373 has been marked as a duplicate of this bug. ***
Comment 7 Buovjaga 2018-05-19 18:38:35 UTC
Bisected to https://cgit.freedesktop.org/libreoffice/core/commit/?id=23391fdb5cffb62006415ad1f4c96b6ed5d50cf8

Adding Armin to CC. Test file coming next.

commit	23391fdb5cffb62006415ad1f4c96b6ed5d50cf8 (patch)
tree	fc25a363096c6ed5d6aa1c58a7bfbdf4ca6d415a
parent	7e2ea27e5d56f5cf767a6718a0f5edc28e24af14 (diff)
tdf#98646 Fixed freeze by flattening loops
DrawViewShell::MakeVisible was using loops for finding the area
to change the visible part of the EditView to. That could (and did)
potentially loop for a long time for very large objects, deep zoom or
numerical problems. That loops were flattened, the results checked
to be the same.
Also added a test for numerical overflow for getting values from the
Rectangle describing the object size. Despite these values being
the result of erraneous import, I opt for checking and avoiding using
these values.

Change-Id: I783dc1f2ad9b6a60a47e660b0d576ea3f22a4e42
Reviewed-on: https://gerrit.libreoffice.org/23278

Also repro on Linux

Arch Linux 64-bit
Version: 6.1.0.0.alpha1+
Build ID: 21b11273ae91f0cf7fd5f3f9fd2168e4349852c4
CPU threads: 8; OS: Linux 4.16; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on May 11th 2018
Comment 8 Buovjaga 2018-05-19 18:39:31 UTC
Created attachment 142210 [details]
Test file

Ctrl-A to select the line, zoom at it to over 100% and start hitting down arrow.
Comment 9 Armin Le Grand 2018-05-24 08:50:20 UTC
Hi Buovjaga,

cannot reproduce (teh loop) in

Version: 6.1.0.0.alpha1+
Build ID: ab64742dc35ede2f02927eef822aaeeeb6a2e234
CPU threads: 8; OS: Windows 10.0; UI render: default; 
Locale: en-US (en_US); Calc: CL

Maybe on Linux the input buffer fills faster/more than on Win?

To make more clear, ew may consider in DrawViewShell::MakeVisible to use bigger distances to the borders to not have the Line 'glued' to upper/lower of SdrPage - sometimes indeeed only tzhe vertical ruler is a hint that something is still moving.
But this is not an error, but would be an enhancement.

As said: I cannot reproduce a crash/endless loop.

BTW: Still have that link to funky japanese music :-)
Comment 10 Buovjaga 2018-05-24 09:15:12 UTC
(In reply to Armin Le Grand (CIB) from comment #9)
> Hi Buovjaga,
> 
> cannot reproduce (teh loop) in

This regression is not about a loop or a crash, but the fact that the upper edge of the screen is following the line. Previously, the line moved and the canvas position did not change.
Comment 11 Armin Le Grand 2018-05-26 18:19:29 UTC
Hi Buovjaga,

maybe we are speaking about different things, not sure, but there is/was always functionality that the shown part of the Page in the View follows the selection. 

If you say 'that the upper edge of the screen is following the line' I think you talk about just that: The shown part is adapted to make the Line (that is selected) still visible in the View.

If you say 'Previously, the line moved and the canvas position did not change.' do you want to express that the Line was moving out of the View and the View was not adapted to still show the line?

If so that was an error. It is by purpose to keep the selection (in this case the Line) visible all times.
Comment 12 Buovjaga 2018-05-27 18:46:14 UTC
Created attachment 142319 [details]
Screenshot showing the problem

The problem is that the upper edge of the screen is glued to the line and the user is having great trouble perceiving the location of the line as it moves.
Comment 13 Armin Le Grand 2018-05-31 08:58:11 UTC
Hi Buovjaga,

yes, that was clear now. Still no answer to:

If you say 'Previously, the line moved and the canvas position did not change.' do you want to express that the Line was moving out of the View and the View was not adapted to still show the line?

Or in other words: Was there once a version where the shown part of the view was *not adapted* when the line was moved - especially when moved outside the visible part ?!?

I think not.

What *might* have been changed are the used distances to adapt the visible part of the view. When you make bigger steps to adapt, there will be room (e.g. when moving up) for some moves without at-once adapting again. That way the user can better understand what happens (he also has the PageView left in your screenshot where the line also moves and the rulers).

Thus the change may be that somehow something (someone?) has changed the preset distances to travel the visible view when the selection leaves it.
If yes, the fix would be to find out about it/increase that travel distance so that there is more room for the next movement steps of the line (in that example)
Comment 14 Buovjaga 2018-05-31 09:32:22 UTC
Created attachment 142434 [details]
Screen recording of moving a line in 3.6.7

(In reply to Armin Le Grand (CIB) from comment #13)
> Hi Buovjaga,
> 
> yes, that was clear now. Still no answer to:
> 
> If you say 'Previously, the line moved and the canvas position did not
> change.' do you want to express that the Line was moving out of the View and
> the View was not adapted to still show the line?
> 
> Or in other words: Was there once a version where the shown part of the view
> was *not adapted* when the line was moved - especially when moved outside
> the visible part ?!?

In the old versions, it is only adapted when you first arrow-move a line: the view is centered.

The attached recording is of the situation where it centered the view and I zoomed in again and started arrow-moving again.
Comment 15 Gary 2018-05-31 14:33:31 UTC
There is a simple way to observe this bug and compare the behavior to non-bug behavior.

Create the test drawing:
1. Open a DRAW to a new page. The entire page should be on screen.
2. Draw a horizontal line, centered vertically in the page. Make the length of the line such that the endpoints are near the left and right page boundaries.

Exhibit non-bug behavior:
A. Use up/down arrow keys to move the line up or down (or alt-arrow to nudge 1 pixel increments). Observe the line moves and the page is stationary.
Note the vertical position of the line after one arrow key press, it is still near the vertical center of the page.
B. Zoom in such that the left and/or right line ends are near the edge of the screen, but still inside the screen. Again use up/down arrow keys. Observe the same behavior as in (A).
Expected behavior: line should move up or down with arrow keys while the page remains stationary. The page should never move unless the line is moved beyond the edge of the screen. The arrow keys are to move the drawing object, not the page.

Exhibit bug behavior:
C. Now zoom in a little more such that one or both ends of the line is just a little off the side of the screen edge. The line should still be centered vertically in the screen (if not, then scroll page vertically until the line is approximately centered vertically). 
Use up/down arrow keys (or alt-arrow) to move the line up or down, one key press only. 
Expected result: the line should move incrementally up or down on the page while the page stays stationary. 
Observed result: the page moves up until the line is at the top edge of the screen. Further up or down arrow key presses moves the page down or up while the line continues to be attached to the upper edge of the screen.
This is BUG behavior.
D. (Alternate error condition) Return to condition in step (B) - line centered vertically on the page, line end points near page edges. Scroll left or right such that the line end point is just a tiny bit off the edge of screen. Press up or down arrow key. Result: page moves down.

DRAW never used to behave like this, and this bug makes it nearly impossible to use the arrow keys to move objects in actual usage. Extremely annoying for DRAW users. This BUG occurs with all drawing objects, not just lines. Circles, rectangles, triangles, etc. are all effected by this bug.
As Regina noted, this bug was introduced sometime around version 5.1 - 5.2. You can install one of the earlier versions and check.
Comment 16 Xisco Faulí 2018-06-05 21:03:21 UTC
Adding Cc: to Armin Le Grand
Comment 17 Armin Le Grand 2018-06-13 08:20:31 UTC
May be fixed with https://gerrit.libreoffice.org/#/c/55156/
Comment 18 Buovjaga 2018-06-13 11:35:16 UTC
Thanks for the tip! Indeed, moving the line appears to work now. Closing as fixed instead of dupe as the reported behaviour was so different.
Comment 19 Xisco Faulí 2018-06-14 09:52:26 UTC
(In reply to Buovjaga from comment #18)
> Thanks for the tip! Indeed, moving the line appears to work now. Closing as
> fixed instead of dupe as the reported behaviour was so different.

Setting to VERIFIED then