insert or link a *.jpg file into a long dokument. After inserting the aktual placeholder goes to end of the document. You have to gob back. Other problems haven`t been seen.
works as it should under 3.4 r1
*** Bug 38538 has been marked as a duplicate of this bug. ***
Created attachment 54919 [details] example document This behaviour is present in two documents; one I share here, one I cannot share. Both documents have no relation. For both docs it might be true that they're "old". In case of the document sent, after inserting a new pic, the doc jumps to the beginning of it. I think hitting ESC jumps back to newly inserted picture. The behaviour was observed consequently during my last 3 days editing of the document. But behaviour is not 100% consequent. NOTE: bug is also present in Main-tree (version 3.6)
I've a movie (.ogv) which demonstrates the behaviour. Let me know where to sent it to. As it is 8M in size. I could not attach it.
I increased the importance as this behaviour is very weird for the average user.
<http://wiki.documentfoundation.org/BugReport_Details#Version> Works fine for me with sample document and "LibreOffice Portable 3.3.3 - WIN7 Home Premium (64bit) German UI [OOO330m19 (Build:301 Tag 3.3.3.1)]", but [Reproducible] with "LibreOffice 3.4.5 RC1 - WIN7 Home Premium (64bit) German UI [Build ID: OOO340m1 (Build:501)]", [Reproducible] with Parallel Dev-Installation of "LibreOffice 3.5.0 Beta2- WIN7 Home Premium (64bit) German UI [Build-ID : 8589e48-760cc4d-f39cf3d-1b2857e-60db978] Not reproducible with every document, only particular ones affected. Until now I do not know what the reason might be. Problem is not limited to .jpg, I tested woth .png and see the same problem. There are also other actions that can cause that jump of focus to the end, like insert horizontal line picture, update indexes, ... It's really annoying, but not critical. @Cédric: Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
*** Bug 43371 has been marked as a duplicate of this bug. ***
*** Bug 40353 has been marked as a duplicate of this bug. ***
I performed mwith my logbook (239 pages, 93 pictures, 7.2MB size), also with the example document. - start Libo - open logbook - using Navigator, go approx. half way (is not critical) - put cursor by mouse click - hit Enter - Insert -> Picture -> From file (.jpg) - now Libo jumps to end of document - perform reload of logbook in Libo; File -> Reload - using Navigator, go half way - put cursor by mouse click - hit Enter - Insert -> Picture -> From file (.jpg) - now Libo jumps to end of document - hit ESC -> Libo returns to right position in doc (== right after inserted picture) Machine 1: Debian Wheezy LibreOffice 3.6.0alpha0+ Build ID: 93d2a2e-7ef74e0-6f9c6e1-libreoffice-3-5 branch-point Libo 3.5beta2 Machine 2: Debian Squeeze Libo 3.4.3 from Debian Backports Issue is NOT present in: Machine 1: Debian Wheezy LibreOffice 3.3.4 OOO330m19 (Build:401) tag libreoffice-3.3.4.1 ====================================================================== Herewith few more observations related to 36681 bug. All observations done using Libo 3.5beta2 running in Debian Wheezy. - start Libo - load lorem_ipsum document - scroll half way - hit ENTER - insert picture - No jump; behaviour is ok - close document - load 01018gs3_beginnenmetbase.odt document (available in bugreport) - scroll half way - hit ENTER - insert picture - Jump to Beginning of Document - hit ESC -> now jump to position right after picture More observations: - hitting ENTER is required in order to get the bug - more then one ENTER's have same effect as one -> bug appears - entering normal text + ENTER's ( so enter paragraph) -> bug does not appear - in failure mode: Libo jumps to end OR to beginning of document - hitting ESC makes jump to correct position in document hypothesis: - bug introduced since 3.4 - bug is side effect of fixing another bug - bug depends on document
Created attachment 55279 [details] small document; newly created which does not show the bug behaviour
Fixed in master branch (3.6): http://cgit.freedesktop.org/libreoffice/core/commit/?id=3d3584237424b8efefdb0579e131892e1ddf00a9
Cherry-picked in 3.5 branch: http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=4463a523ae78a9eff1776668825ec6be944c1574
Hi, thanks for solving. I noticed that removing a picture in 3.5 does a real short jump to page 1 and back to the correct afterwards.
Hello, I checked this bug resolution in LibreOffice 3.6.0alpha0+ Build ID: e60b212-9eed775-d06f752-libreoffice-3-5 branch-point I confirm it is solved, However following sequence is weird: - select a picture frame in the document - click Delete - picture is removed; position in document is OK - click CTRL Z (for Undo) - jump to beginning of document last step is wrong again. So similar observation as Comment 13:
*** Bug 44311 has been marked as a duplicate of this bug. ***
The bug is still present: open a document, scroll to the middle, now insert a frame => scroll to the beginning of the document
@Luc: Please understand that the Version field should always the FIRST version in which a bug is known to exist, and NOT the last one. So please don't "update" the version field, only state in your comments that a bug is still reproducible in a specific new version of LibreOffice. Thank you!
tested agin with 3.6.0.1 with win 7 64, inserted a new picture into a big document with many pictures. the cursor remains at the palce of the picture, I see no problems i think the bug is fixed with windows. also no problems with version 3.5.5 thank you gerdl 17.7.2012
Cedric Bosdonnat committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fb63bdd04119698a2c8e40f946cd222d3114cb7f fdo#36681: fixed view window after redoing a frame delete
I didn't fix the quick display of first page when deleting as it is less annoying and more complex to track down.
(In reply to comment #19) > Cedric Bosdonnat committed a patch related to this issue. > It has been pushed to "master": @Cédric: Thank you very much for fixing this issue -- it was really annoying!
Ok on 3.4.0.beta1 on XP SP3. Moved to verified.
I am using LibreOffice 4.1.2.3 and this issue seems to have reappeared, am I the only one?
(In reply to comment #23) > I am using LibreOffice 4.1.2.3 and this issue seems to have reappeared, am I > the only one? Seems OK for me. Did you try with bugdocs attached to this bug report or with your own files? Best regards. JBF
(In reply to comment #23) > I am using LibreOffice 4.1.2.3 and this issue seems to have reappeared, am I > the only one? Yes.
I see the same problem appearing again in 4.4.0.3 and 4.3.6.1 on Ubuntu 32 bits..
please don't re-open ancient bugs - it is very confusing, please file a new bug instead and put this one in "see also"
Notes for unit test writers: Revert has to be done manually.