Description: ment (there is a grey margin). The text cursor is in window 1. With the graphic cursor, I adjust the width of window 1. The grey margin between the document edges and the window edges is adjusted accordingly in window 1. May be wanted. However, simultaneously, the document is shifted sidewards in window 2, although its width remains the same. Wrong. If a document window is not touched, the document should stand still. Steps to Reproduce: 1. ALT-W 2. n 3. Position windows side by side. 4. With the graphic cursor, adjust width of window 1. Actual Results: The document is shifted sidewards in window 2, although its width remains the same. Expected Results: If a document window is not touched, the document should stand still. Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: This is not actually serious. However, it is confusing to the user because he perceives something happening which was not triggered by himself.
Christian, thank you for reporting the bug. I don't understand description. And how is this report related to bug 141790. Could you please explain? Thank you. => NEEDINFO
Created attachment 171671 [details] Screen video showing sliding document in two windows Document is opened in two windows side by side. Width of main window is adjusted with the graphic cursor. Document slides in its window - may be wanted. However, document also slides in the second window. Should stand still.
(In reply to Christian Lehmann from comment #2) > Width of main window is adjusted with the graphic cursor. Document slides in > its window - may be wanted. Actually, I am not even sure why this should be wanted. I.e., I am not sure why, if the user changes the width of an LO window, the document should move in the window.
[Automated Action] NeedInfo-To-Unconfirmed
I reproduce on Linux, but not on Windows. Christian's video is showing gtk3. Arch Linux 64-bit Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 9a42c99d7b3e8a8429f14d7d851f3d186fa04594 CPU threads: 8; OS: Linux 5.17; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Jumbo Built on 14 April 2022
Here is an observation which may lend additional force to this report (up to now gracefully ignored by developers): - I have two windows open on the same document side by side. I work in Window 1. - I click into Window 2. Simultaneously, that part of the window which displays a page of the document (thus, not the sidebars) is shifted to the left by 1 cm or so, in both windows. - After having worked in Window 2, I click back into Window 1 (to continue work there). However, this click does not actually hit the element over which the visible caret is hovering, but instead an element which is 1 cm to its left in the text. Now what is annoying about this behavior of LO Writer is the possible unwanted effect: The element actually hit by the click may be a clickable one, e.g. a reference to a different section of the document. Then of course I am taken to that section and must navigate my way back manually to the place where I was working. Contrary to what I said in the initial report, this now does seem serious. LO Writer obviously does not know about the shift of the window content and therefore is mistaken about its supposition of what is under the graphic cursor. I hope this is intelligible. Otherwise I can supply another video (I already had supplied one).
Sorry, I forgot to add that the behavior is observed in the LO Writer running in the Windows 10 VM. Thus, the addition "Linux only" on the bug title may be mistaken.
(In reply to Christian Lehmann from comment #7) > Sorry, I forgot to add that the behavior is observed in the LO Writer > running in the Windows 10 VM. Thus, the addition "Linux only" on the bug > title may be mistaken. Well, that was my own testing result on Win vs. Linux, but let's adjust per your findings.
I'd say this is the same issue as bug 116372. *** This bug has been marked as a duplicate of bug 116372 ***