Maybe I missed something... however, though I've entered my name in Tools > Options > LibreOffice ... User data after editing closing and reopening a file, the cursor is at top ..
OK in 4,2,5, wrong in 4.3.0 alpha1 Oh yes, Tools > Options > Load/Save > General ... Load user specific settings is checked too
Confirmed in LO 4.3.0.3 under Windows 7 SP1 x64 This is a very useful/common feature especially for people writing long documents! I think the Importance should be bumped up? BTW this only affects documents created in LO 4.3. If the document was created in a previous version or created in LO 4.3 but modified in a previous version, cursor position works as expected.
Interestingly it works for me in master with 4ca819b204e6c93c4b4e20b191100aa248b8ff23 . Can you please check with master, or provide a document that triggers this or anything? Bibisect would be ideal. For the record, the last cursor position is stored in <config:config-item config:name="ViewLeft" <config:config-item config:name="ViewTop" in settings.xml.
@Kendy: pls test with 4.3.0.x Any text document that I edit, close, and reopen, has the cursor at the top - even in a header if there is one..
*** Bug 82313 has been marked as a duplicate of this bug. ***
I do not reproduce with version 4.3.2.0.0+ (Build ID: e5dd20508ca49fb6e6aee4a12cbf0dab568d7c16) build at home under Ubuntu 14.04 x86-64. I am pretty sure that I never had this problem with all versions of 4.3 I built since the branch-off. @Cor & Pedro: did you try with a clean profile (don't miss to set your personal informations)? Best regards. JBF
(In reply to comment #2) > Confirmed in LO 4.3.0.3 under Windows 7 SP1 x64 > > This is a very useful/common feature especially for people writing long > documents! > > I think the Importance should be bumped up? > > BTW this only affects documents created in LO 4.3. If the document was > created in a previous version or created in LO 4.3 but modified in a > previous version, cursor position works as expected. All of my documents that were affected were created in LO 4.2.0.4 and when saved in LO 4.3.0.4 exhibited this failure to save last cursor position.
(In reply to comment #6) > @Cor & Pedro: did you try with a clean profile (don't miss to set your > personal informations)? Makes no difference..
(This is an automated message.) Setting priority to highest as this is a MAB. This is part of an effort to make the importance of MAB reflected in priority too.
Hello. This bug seems to concern only the Windows version. I have LibO4322 both on Vista 32 bits and on Linux 64 bits: opening places the cursor at last position of editing with Linux version, at the beginning of the document with Windows version. But the LibO4322 Windows version places the cursor at the last position of editing when opening documents saved with a previous LibO42x version. Richard
(In reply to richard_g from comment #10) > This bug seems to concern only the Windows version. Hi Richard. No it does not. I have the problem on Linux.
In reply to Cor Nouws, Comment 11: I confirm that the problem only occurs on my Windows Vista 32 bits installation. I don't have this problem on Linux CentOS 6.4 64 bits with the Version 4.3.2.2 (Build ID: edfb5295ba211bd31ad47d0bad0118690f76407d). Because I am not the administrator on my Linux CentOS 6.4 64 bits workstation, I installed the 4.3.2.2 version in parallel mode besides the official old 3.4.5 version, following this tutorial: https://wiki.documentfoundation.org/Installing_in_parallel/fr So, using this 4.3.2.2 version installed in parallel mode on Linux CentOS 6.4 64 bits, the documents I am working on are always opening with the cursor at the last position of editing. I hope this info will help finding the bug. Richard
Thanks for the additional info Richard. It's a bit weird, not affection all users / situations bug..
I can report that the bug is present in 4.3.2~rc2-0ubuntu1~precise1 installed from the Ubuntu PPA running on a 32-bit Linux Mint 13 Xfce.
*** Bug 84542 has been marked as a duplicate of this bug. ***
(In reply to Cor Nouws from comment #13) > Thanks for the additional info Richard. > It's a bit weird, not affection all users / situations bug.. it affects me as well under Win7x64 either using 4.3.2.2 portable version from winPenPack and normal installation of 4.4.0.0.alpha0+ Build ID: 268b9c10c9ff27c74678ace99762f28d58d33012 TinderBox: Win-x86@42, Branch:master, Time: 2014-10-02_23:35:24
(In reply to Jan Holesovsky from comment #3) > For the record, the last cursor position is stored in > > <config:config-item config:name="ViewLeft" > <config:config-item config:name="ViewTop" > > in settings.xml. I saved a document in 4.3 and opened it with 4.2: the cursor was at the top although I saved it with a different cursor position. Then I moved the cursor somewhere else and saved the document in 4.2. After reopening the document in 4.2 the cursor was correctly at the stored position. Afterwards I compared the two instances of settings.xml and realized the following: In 4.2 the config items "ViewLeft" etc. were of type "int", whereas in 4.3 they were of type "long". (More precisely, all items of type "int" in 4.2 were of type "long" in 4.3.) Then, for the hack of it, I replaced all occurences of "int" with "long" and 4.2 opened the document at the right cursor position saved by 4.3 (although the display of pages was a bit bizarre). Maybe this can give a hint at where the bug is?
(In reply to Olibuntu from comment #17) > Maybe this can give a hint at where the bug is? Indeed. @kendy ? NB: Yesterday I opened _some_ documents from few years back that do have the correct position. New /recent documents don't..
It's not just the Windows version. I've had this in Linux x86(deb) since: Version: 4.3.1.2 Build ID: 958349dc3b25111dbca392fbc281a05559ef6848 Just tried upgrading to: Version: 4.3.2.2 Build ID: edfb5295ba211bd31ad47d0bad0118690f76407d but no improvement. (Note that Shift+F5 doesn't work either.) Older files (saved pre 4.3) do still open at the last saved position. Downgrading to: Version: 4.2.6.3 Build ID: 3fd416d4c6db7d3204c17ce57a1d70f6e531ee21 solves the issue, so if this is an important feature for you (it is to me!) I suggest you stay away from 4.3 till it's fixed.
(In reply to Geoff from comment #19) > ... so if this is an important feature for you (it is to me!) > I suggest you stay away from 4.3 till it's fixed. Hi Geoff! Well, I do like the feature, but missing all the improvements in later versions for this glitch ... No, not me ;)
Still present in 4.3.3.1 (build ID 7d55112667c8fcddb67bc3803796b46c93aa56b0) under 32-bit Linux.
Hello. I recall a part of my comment 10 that you may have missed: "But the LibO4322 Windows version places the cursor at the last position of editing when opening documents saved with a previous LibO42x version." LibO43X is able to read the last position of editing but is not able to save it. Richard
Further to Richard's comment (Comment 22): I've noticed that Writer documents saved under 4.2 open correctly (at the last cursor position) in 4.3, but re-saving the document in 4.3 and opening it again (in either 4.2 or 4.3) takes me to the start of the document. So, a suggested testing scenario: - In 4.2: Create and save a document. - In 4.3: Open the document. Cursor will be where you left it. - Make a change, save and close the document. - Re-open it. The cursor position will be lost.
> - In 4.2: Create and save a document. > - In 4.3: Open the document. Cursor will be where you left it. > - Make a change, save and close the document. > - Re-open it. The cursor position will be lost. Same in 4.3.3.2 :(
--> jflash@mail.ee you changed the status to ASSIGNED. this means that you are planning to patch the code and fix the bug, is that correct or was it a mistake?
(In reply to tommy27 from comment #25) > --> jflash@mail.ee > you changed the status to ASSIGNED. > this means that you are planning to patch the code and fix the bug, > is that correct or was it a mistake? I am sorry! This was mistake. Im read Status description (https://www.libreoffice.org/bugzilla/page.cgi?id=fields.html#bug_status) but does not find information about them. I hope NEW is correct.
It seems to be 32 vs 64 bit. For both I tested with kubuntu 14.10 livecd, so that the system is exactly the same except one is 32-bit and the other 64-bit. (A note for Windows users: Even if your Windows is 64-bit, LibreOffice *itself* is 32-bit.)
(In reply to Maxim Monastirsky from comment #27) > It seems to be 32 vs 64 bit. For both I tested with kubuntu 14.10 livecd, so > that the system is exactly the same except one is 32-bit and the other > 64-bit. (A note for Windows users: Even if your Windows is 64-bit, > LibreOffice *itself* is 32-bit.) Can you clarify this, Maxim? Are you getting the bug in the 32-bit or the 64-bit versions? (I'm guessing 32-bit.) And I'm also guessing you're also running both liveCDs on a 64-bit machine. FWIW, in my own testing I get the bug on both 32-bit and 64-bit Linux machines -- actual installations, not liveCDS. As I typically work on large documents (typically up to 300 pages), this bug's an upgrade deal-breaker for me.
(In reply to Geoff from comment #28) > Can you clarify this, Maxim? Are you getting the bug in the 32-bit or the > 64-bit versions? (I'm guessing 32-bit.) Right. > And I'm also guessing you're also running both liveCDs on a 64-bit machine. Of course. How could I run 64-bit livecd on a 32-bit machine? > FWIW, in my own testing I get the bug on both 32-bit and 64-bit Linux > machines 64-bit linux with 64-bit LibreOffice? > actual installations, not liveCDS. I have actual installation of Fedora 21 64-bit on my laptop, and I can't reproduce it there.
Hi Tor, It seems to me a regression of 84272d11. Previously we were writing long to the file, so the 32-bit version wrote 32-bit values (represented in settings.xml as "int"), and the 64-bit version wrote 64-bit values ("long" in settings.xml), so there was no problem in reading this back to long on the same platform. But at least since 84272d11 we're writing 64-bit on all platforms, because that's what convertTwipToMm100 returns (see SwView::WriteUserDataSequence). So we have a problem reading this back to long (in SwView::ReadUserDataSequence) on 32-bit platforms, because the >>= operator of Any doesn't handle 64-to-32 bit conversion.
*** Bug 86797 has been marked as a duplicate of this bug. ***
Whiteboard:bibisectRequest removed and keywords:bisected added to indicate that the commit which caused this regression has been identified
(In reply to Matthew Francis from comment #32) > Whiteboard:bibisectRequest removed and keywords:bisected added to indicate > that the commit which caused this regression has been identified Well, that was just a guess. I don't have 32-bit build to actually check my assumptions.
It seems like a pretty good guess, and in any case I can't reproduce the bug with the bibisect repositories (which are 64-bit) so it's probably not bibisectable to begin with
*** Bug 61870 has been marked as a duplicate of this bug. ***
Same problem here. Version: 4.3.5.1 OS: Windows XP
Same problem on Win7/64bit and 4.3.5 release. Please fix this bug ASAP as it is really annoying while writing or editing long documents. This bug renders the 4.3.x line unusable for me up to now! Staying with 4.2.8 until this is fixed!
Adding bibisected to whiteboard as bisected keyword is a subset of bibisected whiteboard. Thanks!
I would like to raise the importance of this bug to make it more likely that it will be fixed in one of the two last 4.3.x releases. Any agrees, any objections?
(In reply to chris.hoe from comment #39) > I would like to raise the importance of this bug to make it more likely that > it will be fixed in one of the two last 4.3.x releases. > Any agrees, any objections? Hi Chris, I think no one will disagree in raising the likely-ness that this will be fixed. Setting status or whatever higher will not make any difference however. But if you have opportunity, it could be of great help if you can create a test pack, with e.g. - older file A behaves fine in older version and newer LibreOffice - older file B does not behave OK in newer LibreOffice - new file C B does not behave OK in newer LibreOffice - .. ? In comment 3 kendy gives some pointers for information that can be retrieved from teh xml files in the odt-zip and that are possibly involved. Regards, Cor
Comment 30 is correct, but this is only one of the reasons why it does not work. Even when config items were 'int', it did not work for me on Windows and Mac. However, it worked on 32-bit Linux.
I can confirm Andras comment (comment 41) - changing ViewLeft and ViewTop to int manually doesn't change the behaviour on my Win7/64 system. The cursor is still on top of the document after reopening. Cor, I will try to prepare something for testing tonight although it's pretty straight forward: a) ODT-Files saved in LO versions up to 4.2.x opens OK in older and newer LO versions. b) ODT-Files saved in LO versions 4.3.x and newer open always on the first page with old and new LO versions. There are no other cases, so your case b) doesn't exist. Regards, Chris
Hi Chris, (In reply to chris.hoe from comment #42) > I will try to prepare something for testing tonight although it's pretty > straight forward: > [...] It that really are all the scenario's, then it would add little to prepare extra documents. Main item is that people testing it have a version of LibreOffice 4.2.x available for the documents that behave correctly. thanks for your help Cor (who in the mean time adds XXXX to the documents he's editing over the other day ;) )
Ditto for me in version 4.2.8.2. So this is not just an alpha release bug, as far as I can see. The bug is already present and well entrenched in the latest official release candidate. Very annoying indeed.
I am using Ubuntu 14.04 which defaults to LibreOffice version 4.3.5.2, Build ID: 430 m0(Build2), and I have the problem too. It is very annoying. So much so that I reverted to Ubuntu 12.04 on my new machine which will allow me to install LibreOffice 3.5.7.2 Build ID: 350m1(Build:2). I would like to upgrade to Ubuntu 14.04 or even Ubuntu 14.10 but I won't do so until this issue is resolved. This is a very important issue for me when working on large documents. Does anyone know if there is any progress on this issue? Is anyone working on it? Does anyone know how to install an older version of LibreOffice on a machine running Ubuntu 14.04? Out of the box 3.5.7.2 won't run on Ubuntu 14.04.
(In reply to Mrs Weaver from comment #45) > I am using Ubuntu 14.04 which defaults to LibreOffice version 4.3.5.2, Build > ID: 430 m0(Build2), and I have the problem too. It is very annoying. So > much so that I reverted to Ubuntu 12.04 on my new machine which will allow > me to install LibreOffice 3.5.7.2 Build ID: 350m1(Build:2). I would like to > upgrade to Ubuntu 14.04 or even Ubuntu 14.10 but I won't do so until this > issue is resolved. This is a very important issue for me when working on > large documents. Does anyone know if there is any progress on this issue? > Is anyone working on it? Does anyone know how to install an older version > of LibreOffice on a machine running Ubuntu 14.04? Out of the box 3.5.7.2 > won't run on Ubuntu 14.04. To correct my previous entry 14.04 defaults to LibreOffice 4.2.6.3 which I upgraded to 4.3.5.2 to see if the bug had been resolved. It has not. It didn't work with 4.2.6.3 and it doesn't work with 4.3.5.2.
This bug desparately needs a conclusive summary of all finding so far.
(In reply to Björn Michaelsen from comment #47) > This bug desparately needs a conclusive summary of all finding so far. I think that comment 30 and comment 42 give the important information
Jan Holesovsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c99e634e06aa97d9230d9200206e9c2e8e373ed0 tdf#80960: Attempt to fix the cursor placement after document load. It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I tried exactly the same patch a couple of days ago, but it did not help. Probably it is required, because otherwise we always read 0, but it is not enough. I did not have the time to create a 32-bit debug build, but I'm starting one now.
I downloaded this build today: master~2015-02-03_06.37.21_LibreOfficeDev_4.5.0.0.alpha0_Win_x86 and now cursor saves position under win7 pro 32 bit.
(In reply to jflash from comment #51) > I downloaded this build today: > master~2015-02-03_06.37.21_LibreOfficeDev_4.5.0.0.alpha0_Win_x86 and now > cursor saves position under win7 pro 32 bit. Thanks for testing and reporting your result jflash. However I've not yet had the opportunity to test on my 32 bits system. So I reopen for now.
most recent version available for me Versie: 4.5.0.0.alpha0+ Build ID: d1c9bd13ec7af93f5368dfda6d6d3c955f0b0816 TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2015-01-28_00:25:56 Locale: nl_NL still has the bug.
*** Bug 89157 has been marked as a duplicate of this bug. ***
I'm not sure if this helps to provide clues: I had to force terminate LO4.4 (with Task Manager) after it stalled having resumed from hibernation (on Win7 64bit). Upon restarting LO, it (expectedly) offered to recovered 2 files. Upon reopening the files, one of them (the much long one) opened where I left it! But not the other. This I've tested 3 times with the same result. (Meanwhile, looks like I'll be force terminating LO for some while... )
I should add: What I mean to say is that reopening that longer file the normal way places the cursor in the beginning, but when opened by recovery I get to have it where I last saved the file, though the cursor is not on the page.
Unfortunately I have to confirm that the most recent version available for me, which is... Version: 4.5.0.0.alpha0+ Build ID: 1845b6af3991ca5521eef48aafe1d0489e2ff8f6 TinderBox: Win-x86@42, Branch:master, Time: 2015-02-02_09:30:48 Locale: de_DE on my System: Win7, 64bit, German which I just downloaded and installed for testing still has this annoying bug! Looks like the fix from comment #49 doesn't do the whole magic. So, on my computers (all Win7, 64bit) the situation is unchanged: * any version up to and including 4.2.8 works as expected * any version from 4.3.0 shows the "cursor on first page" bug * the daily build from master at 2015-02-02 still shows the bug Any document with more than one page could be used for testing. I hope that this summary helps to spot and eliminate this really annoying and surprisingly persistent bug!
Can confirm this bug for all my LO versions starting from 4.3.0 on Windows 7/8 platforms
Next week this really annoying bug gets 9 month old - and is still present! Moreover, it seems that no one really takes the challenge to drill it down and fix it. Now we can imagine why generations of MS Word versions showed the stupid "page 1 of 1, page 2 of 2, page 3 of 3, ..." bug - creating new features seems to be more attractive to developers than fixing broken old ones. :-( Come on guys - let's fix it! I do not know enough about this huge project to fix it by myself but I'm willing to assist in any possible way. PLEASE!!!
I regret that I have to say that the most recent version available for me, which is... Version: 4.5.0.0.alpha0+ Build ID: 0986fe775563a9fd2a463f1c1b288fb5209b0b52 TinderBox: Win-x86@42, Branch:master, Time: Time: 2015-03-31_07:17:19 Locale: de_DE on my System: Win7, 64bit, German performs even worse than the versions I've tried before. This version even fails to load the saved cursor position with documents saved with LO version 4.2.8 and older! With that, this version NEVER places the cursor to the saved position but ALWAYS puts it to the top of the document which makes no difference in practical cases of continuous editing of a document but is still a step in the wrong direction. :-(
(In reply to chris.hoe from comment #60) I understand you are not happy with the current situation; you're not alone. The most recent version you tried, 4.5.0.0alpha0+, also called 'master', is unreliable by default, as all changes are being tested and tried here. The cause of this bug has to do with a fundamental change in version 4.3 with many benefits (you would probably scream if they were removed), but some unwanted side effects, which were not noticed during testing. This bug is such a side effect, and not easy to solve either, otherwise it would have been fixed much sooner. I you really want to have it fixed asap, I see two options: 1. you start working on the code yourself; lots of developers are willing to help you starting. 2. you pay for the fix and have a professional developer fix the bug. Cluttering this bug report with cries and shouts will only make the comments that _are_ relevant to fixing this bug more difficult to find, with the result that fixing will atke longer. Something you wouldn't want, I figure. ATB, Winfried
Please stop messing with the top settings that you know absolutely nothing about how it works. Reverting all previous changes. http://joelmadero.wordpress.com/2014/10/11/user-expectations-and-the-reality-of-our-community/
Hi Joel, Looking at duplicates and how it breaks many people's work flow, I only wonder why I didn't add it to the MAB list myself earlier :) What do I see wrong here? Cheers, Cor
MAB 4.3 is fine - it was added to 4.4 also (we don't put things on two MAB lists) it was also raised to "critical" which this is not at all critical....it's stretching even "major" to the limits of the objective priority. So 4.3 mab is where it belongs, major - highest is good enough :) Thanks for checking Cor :-D
(In reply to Joel Madero from comment #64) > So 4.3 mab is where it belongs, major - highest is good enough :) Thanks for > checking Cor :-D Ah yes. thanks for checking. I'll add it there. (OTOH, looking at efforts already made by several devs, the issue will not be unnoticed..)
Resolved fixed on 32-bit builds for 4.5.0 Bisect result... http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=d1c9bd13ec7af93f5368dfda6d6d3c955f0b0816..4b9a9ce8a0e5e0716dad9a9ec87d16237e534dc2 Kendy's blind patch got it... http://cgit.freedesktop.org/libreoffice/core/commit/?id=c99e634e06aa97d9230d9200206e9c2e8e373ed0 But, this is not perfect as the convertTwipToMm100 of ViewTop and ViewLeft is misplacing the cursor by as much as a dozen characters. 4.3 may be a lost cause, but need a backport to 4.4 Folks should test a current 32-bit master with complete user data (first/last/initials) as well as verifying that <Shift>+F5 gets the Edit View cursor close to last position. Closing this--but leaving bug 82300 open to refine cursor placement.
Please test with these sample documents https://bugs.documentfoundation.org/attachment.cgi?id=112456 https://bugs.documentfoundation.org/attachment.cgi?id=113167 With builds of Master after c99e634e06aa97d9230d9200206e9c2e8e373ed0 (2015-01-28) any existing document opened on 32-bit builds must be opened and edited to reestablish valid Edit View ViewTop and ViewLeft values. When properly cast values are present, the <Shfit>+F5 Restore Edit View shortcut will position the document cursor near to the last edited/saved position for the document. If User Data has been recorded to the user profile, on reopening with build of master later than 2015-01-28, the document should open with cursor positioned near the last edited character. Note: the new Edit View settings for these documents will not be backward compatible for 4.4 or earlier builds. Simply reopen and edit them in older 32-bit builds to reestablish the int based Edit View values--of limited utility.
(In reply to V Stuart Foote from comment #66) > Resolved fixed on 32-bit builds for 4.5.0 ... > Folks should test a current 32-bit master with complete user data > (first/last/initials) as well as verifying that <Shift>+F5 gets the Edit > View cursor close to last position. Indeed :) Tested on Version: 4.5.0.0.alpha0+ Build ID: 9efd80ac32a80656ed6482df69615227d12bc6d9 TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2015-03-30_16:43:31 Locale: nl_NL Thanks Kendy & all others that putt effort in testing, reporting, fixing and so on! And indeed, backport to 4.4 branch would be great.
I really apologize for the trouble I've caused by changing settings of this ticket ... but at least it caused some movement from which the best is that now a backport to 4.4 seems to be planed. ;-) I just again downloaded the latest daily build to verify Cor Nouws findings of comment #68, double checked the user settings (name, given name AND initial) and... voilá yes, I can confirm, that the cursor position is now approximately saved! Tested with: Version: 4.5.0.0.alpha0+ Build ID: 0986fe775563a9fd2a463f1c1b288fb5209b0b52 TinderBox: Win-x86@42, Branch:master, Time: 2015-03-31_07:17:19 Locale: de_DE on Win7, 64bit, DE Why it didn't worked yesterday I can only guess as I've already deleted that installation. Either it was a glitch in specifically this build (which seems very unlikely to me) or I might have missed out the initial in the user data ... which means it is most likely my mistake and I'm really sorry for that. Now you can hit me for my mistake, my behaviour (which never was meant to be unkind...) and everything ... but if it helped initiating a backport to 4.4 it is worth it! Many thanks for all the good work and please carry on! Thanks guys!!! I'm really looking forward to a 4.4 release containing the fix!
(In reply to V Stuart Foote from comment #66) > But, this is not perfect as the convertTwipToMm100 of ViewTop and ViewLeft > is misplacing the cursor by as much as a dozen characters. 4.3 may be a lost > cause, but need a backport to 4.4. Good enough for me. Thanks a lot! And yes, please, please backport to 4.4. I've been holding back upgrading because the bug is just too much hassle for me, with a 98-page file. (I'm writing a book.)
In the case of a successful backport, would it be indicated here?
Yes you will see target:4.4.0 in the whiteboard :) That being said, if it's a pretty serious fix, it might not get backported (if there is concern of regressions). I'll leave that to the experts to figure out :)
Jan Holesovsky committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5087e4caa4343a1a17ffb42eea4aa0354cab8636&h=libreoffice-4-4 tdf#80960: Attempt to fix the cursor placement after document load. It will be available in 4.4.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #73) > Jan Holesovsky committed a patch related to this issue. > It has been pushed to "libreoffice-4-4": > > It will be available in 4.4.3. Alright! Thanks to everyone who contributed! Looks like I'm finally moving out from 4.1.6.2 (after 2 "false starts").
Confirmed fixed in Version: 4.4.3.1 Build ID: b2f347f2ac68821efc00b6f1793cda90af748118 under Windows XP Pro x86 SP3 Thank you Kendy!
Not fixed for me, unfortunately. I’m running LO 4.4.3.1 on Windows 7 SP 1. The behaviour when reopening a Writer document is now different, but not correct. The document now opens at the last page edited, however the cursor is not at the position it was when saved, but in the page header (at the end of the header). The document should open with the cursor in the position where it was when last saved.
(In reply to Kim Bastin from comment #76) > Not fixed for me, unfortunately. I’m running LO 4.4.3.1 on Windows 7 SP 1. > The behaviour when reopening a Writer document is now different, but not > correct. The document now opens at the last page edited, however the cursor > is not at the position it was when saved, but in the page header (at the end > of the header). > > The document should open with the cursor in the position where it was when > last saved. No, this is Resolved Fixed--do not Reopen. Remaining issue of imprecise cursor placement on Reopen or <Shift>+F5, is bug 82300
(In reply to Kim Bastin from comment #76) > Not fixed for me, unfortunately. I’m running LO 4.4.3.1 on Windows 7 SP 1. Please confirm you have actually entered data in all fields in Tools -> Options -> User Data e.g. First/last-name/initials each has a value, and then save and reopen the document. On reopen the document will automatically reposition to vicinity of last edit. Also, in a related but completely separate routine, <Shift>+F5 will reposition (~approximately) to the last edited position recorded into the document.
Jan Holesovsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8f91f1bc16147a931469873b1a9f41ba9da1c73d tdf#80960: Attempt to fix the cursor placement after document load. It will be available in 5.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I confirm that all fields in User Data have (and also previously had) a value. On reopening, the cursor is placed in the page header, not in the text where it was on saving.
Created attachment 114848 [details] test ODT with header, last edit position on page 3 @Kim, (In reply to Kim Bastin from comment #80) > I confirm that all fields in User Data have (and also previously had) a > value. On reopening, the cursor is placed in the page header, not in the > text where it was on saving. Please open a new issue and attach a test document to it, more completely describe STR. Meanwhile attached is a document created in 4.4.3.1 with some header text, and with 3 pages of junk text. Last saved position is on page 3, cursor a space after "Test" On Windows 7 sp1, 64-bit en-US. Correctly responds to <Shift>+F5, or if User identity is present opens to that location with 4.4.3.1 Version: 4.4.3.1 Build ID: b2f347f2ac68821efc00b6f1793cda90af748118 Locale: en_US
Already enjoying for more then a week the great pleasure that this has been fixed. Thanks all that helped :) !
At least, problem solved in Libre Office 4.4.3.2 ! Thank you very much, Libre Office team and others !!!
Still present in 5.0.0.0.Beta1 Build ID: 0a16c3dda4150008d9be6f24cbd15ac198d116d3
Correction to my previous: it works after all, after I entered my name in the Personal data fields. :8
works fine for me in 5.0.0beta1. With given name and sir name added in Tools > Options > LibreOffice ... of course.
ah, seeing your latter comment only now - fifo handling here ;)
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]