Description: https://drive.google.com/file/d/1_d1cXlZu3w4mchU2D_WP_Nw0cvgp7lO2/view?usp=sharing Such things can't be textually expressed to the fullest extent, they have to be experienced. Please download the file and play with it to gain understanding Steps to Reproduce: 1. Put images one above the other 2. Select it by left-click 3. Deselect it by right-click 1. Select an image by left-click 1. Select an image by left-click 2. Drag it Actual Results: 1. It pushes you to the beginning of the page always 2. It shakes your position, but sometimes it does not 3. Same as 2 Expected Results: 1,2,3 - no position change Reproducible: Always User Profile Reset: No Additional Info: In the video
Created attachment 203830 [details] File in the video
(In reply to Danat from comment #0) > Steps to Reproduce: > 1. Put images one above the other > 2. Select it by left-click > 3. Deselect it by right-click Correction: 1. Put images one above the other 2. Select one of them by left-click 3. Deselect it by left-click
(In reply to Danat from comment #2) > (In reply to Danat from comment #0) > > > Steps to Reproduce: > > 1. Put images one above the other > > 2. Select it by left-click > > 3. Deselect it by right-click > > Correction: > > 1. Put images one above the other > 2. Select one of them by left-click > 3. Deselect it by left-click But they can also be deselected by right-click on the background
https://drive.google.com/file/d/1omRv-qDDMuu0Gt9RYZBtFJXG0kq1-qLX/view?usp=sharing 1. Image-toolbar shows up and does a little shaking 2. If you drag an image that is partially outside the screen - the app thinks you have to be pushed to that place where its part is hidden
(In reply to Danat from comment #1) > Created attachment 203830 [details] > File in the video Repro with document. 1. Scroll down a bit 2. Select Image2 3. Deselect by clicking outside canvas View jumps to the top. Repro already in oldest of Linux 43all bibisect repo. In some repos I tested in the 7.x versions, the images were not displayed at all, the document was like a flat line. Arch Linux 64-bit Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d0d81540a7f1e4b2c0b7a305f9f64c518edec8c3 CPU threads: 8; OS: Linux 6.17; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 5 November 2025
(In reply to Buovjaga from comment #5) > (In reply to Danat from comment #1) > > Created attachment 203830 [details] > > File in the video > > Repro with document. > > 1. Scroll down a bit > 2. Select Image2 > 3. Deselect by clicking outside canvas > > View jumps to the top. > > Repro already in oldest of Linux 43all bibisect repo. In some repos I tested > in the 7.x versions, the images were not displayed at all, the document was > like a flat line. > > Arch Linux 64-bit > Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: d0d81540a7f1e4b2c0b7a305f9f64c518edec8c3 > CPU threads: 8; OS: Linux 6.17; UI render: default; VCL: gtk3 > Locale: fi-FI (fi_FI.UTF-8); UI: en-US > Calc: CL threaded > Built on 5 November 2025 I truly don't think that you have to be pushed when the dragged image is partially outside the screen It won't shake you when the dragged images wholly fit in the screen, but it makes an ugly repositioning when the dragged image does not fit in the screen It gave me a fair amount of pain while working
(In reply to Danat from comment #6) > I truly don't think that you have to be pushed when the dragged image is > partially outside the screen > > It won't shake you when the dragged images wholly fit in the screen, but it > makes an ugly repositioning when the dragged image does not fit in the screen > > It gave me a fair amount of pain while working https://drive.google.com/file/d/1Nh9cO3LV_lJmkWEatc_lWco_je4BGgqs/view?usp=sharing
This is not a "view jump". You have a long single page, with a single paragraph at the very top, and a lot of images one after another, all of them anchored to the same paragraph at the top. When you deselect an image, what do you think must happen? What *actually* happens is that you *put cursor* to the text that is nearest to the place where you clicked. And that text is - the single empty paragraph at top. And when you put cursor anywhere, the view must go to show you that place. This is completely valid behavior.
(In reply to Mike Kaganski from comment #8) > This is not a "view jump". > > You have a long single page, with a single paragraph at the very top, and a > lot of images one after another, all of them anchored to the same paragraph > at the top. > > When you deselect an image, what do you think must happen? What *actually* > happens is that you *put cursor* to the text that is nearest to the place > where you clicked. > > And that text is - the single empty paragraph at top. And when you put > cursor anywhere, the view must go to show you that place. > > This is completely valid behavior. In what cases can that be useful? Is there anybody who practically benefits from this behavior? I'm not arguing that it's not useful, but right now I only see how it's inconvenient
(In reply to Danat from comment #9) > In what cases can that be useful? Is there anybody who practically benefits > from this behavior? I'm not arguing that it's not useful, but right now I > only see how it's inconvenient When anyone clicks anywhere, they *always* expect the cursor to appear at the closest place to the clicked point. No one is required to click at 100% perfect coordinate. Just create a Writer document, put there some text, and check your own work with respect to mouse clicks. When you have images there, it doesn't change. You may have an image selected; and then you click to the right or below of some text, and continue typing there. In your case, you have a pathologic document, which behaves the same (I don't discuss that Writer is not the app one should use for such things - Draw would be better; that's orthogonal).
(In reply to Mike Kaganski from comment #10) > (In reply to Danat from comment #9) > > In what cases can that be useful? Is there anybody who practically benefits > > from this behavior? I'm not arguing that it's not useful, but right now I > > only see how it's inconvenient > > When anyone clicks anywhere, they *always* expect the cursor to appear at > the closest place to the clicked point. No one is required to click at 100% > perfect coordinate. Just create a Writer document, put there some text, and > check your own work with respect to mouse clicks. > > When you have images there, it doesn't change. You may have an image > selected; and then you click to the right or below of some text, and > continue typing there. > > In your case, you have a pathologic document, which behaves the same (I > don't discuss that Writer is not the app one should use for such things - > Draw would be better; that's orthogonal). By the way, from where have you gotten that it's anchored to paragraph? It is not if I don't misunderstand. The anchor on all images is "to character". What did you mean by that?
And look at it from another perspective. At any point, in Writer there is *some* position that is "current": it may be text cursor, or it may be a graphic selected ... so that at any point, you know what happens when you e.g. press Del key: in case of text cursor, the text to the right of it will be deleted; when it's an image, it gets deleted ... the current active position defines all sorts of "what happens when I do this and that". So - what *should* be the current active position in Writer, when you clicked like you do in your case? You didn't select another image. Writer has to activate cursor - and there is only one way how it can be done.
(In reply to Danat from comment #11) > By the way, from where have you gotten that it's anchored to paragraph? It > is not if I don't misunderstand. The anchor on all images is "to character". > What did you mean by that? It is immaterial. I didn't care to check if it's to paragraph or to character. It doesn't change a tiny bit.
I think this is now fixed by dbe29bc354105314e83edf7069ba34caf73956eb Revert "Prevent cursor invalidation if the cursor position doesn't change." I pulled the latest changes and built and I don't see the view jump anymore. So I think I'll close as fixed.
(In reply to Buovjaga from comment #14) > I think this is now fixed by dbe29bc354105314e83edf7069ba34caf73956eb > Revert "Prevent cursor invalidation if the cursor position doesn't change." > > I pulled the latest changes and built and I don't see the view jump anymore. > So I think I'll close as fixed. I confirm, no longer can see it