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
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
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.
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.
The bug has been introduced between Version: 5.2.0.0.alpha0+ and Version: 5.1.6.1, see duplicate bug 114373.
*** Bug 114373 has been marked as a duplicate of this bug. ***
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
Created attachment 142210 [details] Test file Ctrl-A to select the line, zoom at it to over 100% and start hitting down arrow.
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 :-)
(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.
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.
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.
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)
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.
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.
Adding Cc: to Armin Le Grand
May be fixed with https://gerrit.libreoffice.org/#/c/55156/
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.
(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