Bug Hunting Session
Bug 80960 - EDITING Opening file doesn't place cursor on last position of saving (see comment 30 and comment 42)
Summary: EDITING Opening file doesn't place cursor on last position of saving (see com...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.0.0.alpha1
Hardware: x86 (IA32) All
: highest major
Assignee: Not Assigned
URL:
Whiteboard: target:5.0.0 target:4.4.3
Keywords: bibisected, bisected, regression
: 82313 84542 86797 89157 (view as bug list)
Depends on:
Blocks: Saved-Cursor mab4.3
  Show dependency treegraph
 
Reported: 2014-07-05 22:34 UTC by Cor Nouws
Modified: 2018-03-13 10:56 UTC (History)
24 users (show)

See Also:
Crash report or crash signature:


Attachments
test ODT with header, last edit position on page 3 (27.17 KB, application/vnd.oasis.opendocument.text)
2015-04-17 03:42 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Cor Nouws 2014-07-05 22:34:39 UTC
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 ..
Comment 1 Cor Nouws 2014-07-05 22:39:47 UTC
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
Comment 2 Pedro 2014-07-20 09:53:08 UTC
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.
Comment 3 Jan Holesovsky 2014-07-23 16:52:29 UTC
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.
Comment 4 Cor Nouws 2014-08-08 08:08:27 UTC
@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..
Comment 5 Cor Nouws 2014-08-08 08:08:49 UTC
*** Bug 82313 has been marked as a duplicate of this bug. ***
Comment 6 Jean-Baptiste Faure 2014-08-08 17:36:04 UTC
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
Comment 7 Jerry 2014-08-08 18:33:03 UTC
(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.
Comment 8 Cor Nouws 2014-08-11 11:45:32 UTC
(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..
Comment 9 Björn Michaelsen 2014-08-21 12:17:22 UTC
(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.
Comment 10 richard_g 2014-10-03 10:47:55 UTC
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
Comment 11 Cor Nouws 2014-10-03 11:13:02 UTC
(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.
Comment 12 richard_g 2014-10-03 13:17:38 UTC
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
Comment 13 Cor Nouws 2014-10-03 21:05:59 UTC
Thanks for the additional info Richard.
It's a bit weird, not affection all users / situations bug..
Comment 14 Olibuntu 2014-10-04 07:55:06 UTC
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.
Comment 15 Owen Genat (retired) 2014-10-05 05:33:29 UTC
*** Bug 84542 has been marked as a duplicate of this bug. ***
Comment 16 tommy27 2014-10-05 11:36:54 UTC
(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
Comment 17 Olibuntu 2014-10-08 15:16:03 UTC
(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?
Comment 18 Cor Nouws 2014-10-08 15:26:13 UTC
(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..
Comment 19 Geoff 2014-10-11 08:31:10 UTC
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.
Comment 20 Cor Nouws 2014-10-11 11:46:11 UTC
(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 ;)
Comment 21 Mihkel Tõnnov 2014-10-12 15:59:57 UTC
Still present in 4.3.3.1 (build ID 7d55112667c8fcddb67bc3803796b46c93aa56b0) under 32-bit Linux.
Comment 22 richard_g 2014-10-13 07:58:58 UTC
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
Comment 23 Geoff 2014-10-13 19:11:31 UTC
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.
Comment 24 jflash 2014-10-30 12:59:24 UTC
> - 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 :(
Comment 25 tommy27 2014-10-30 13:22:24 UTC
--> 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?
Comment 26 jflash 2014-10-31 06:13:30 UTC
(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.
Comment 27 Maxim Monastirsky 2014-10-31 10:54:26 UTC
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.)
Comment 28 Geoff 2014-11-25 21:38:32 UTC
(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.
Comment 29 Maxim Monastirsky 2014-11-25 21:56:27 UTC
(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.
Comment 30 Maxim Monastirsky 2014-11-26 10:44:23 UTC
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.
Comment 31 Cor Nouws 2014-11-27 17:58:17 UTC
*** Bug 86797 has been marked as a duplicate of this bug. ***
Comment 32 Matthew Francis 2014-12-07 01:40:40 UTC
Whiteboard:bibisectRequest removed and keywords:bisected added to indicate that the commit which caused this regression has been identified
Comment 33 Maxim Monastirsky 2014-12-07 13:08:42 UTC
(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.
Comment 34 Matthew Francis 2014-12-07 13:25:51 UTC
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
Comment 35 raal 2014-12-15 14:16:27 UTC
*** Bug 61870 has been marked as a duplicate of this bug. ***
Comment 36 Domenico Ferrari 2014-12-18 14:31:47 UTC
Same problem here.
Version: 4.3.5.1
OS: Windows XP
Comment 37 chris.hoe 2015-01-05 11:25:37 UTC
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!
Comment 38 Joel Madero 2015-01-05 17:15:14 UTC
Adding bibisected to whiteboard as bisected keyword is a subset of bibisected whiteboard.

Thanks!
Comment 39 chris.hoe 2015-01-19 07:32:05 UTC
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?
Comment 40 Cor Nouws 2015-01-19 09:17:25 UTC
(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 41 Andras Timar 2015-01-21 14:37:40 UTC
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.
Comment 42 chris.hoe 2015-01-23 09:51:17 UTC
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
Comment 43 Cor Nouws 2015-01-23 10:26:13 UTC
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 ;) )
Comment 44 franklekens 2015-01-24 07:14:12 UTC
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.
Comment 45 Mrs Weaver 2015-01-25 20:45:41 UTC
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.
Comment 46 Mrs Weaver 2015-01-25 20:53:49 UTC
(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.
Comment 47 Björn Michaelsen 2015-01-27 21:42:37 UTC
This bug desparately needs a conclusive summary of all finding so far.
Comment 48 Cor Nouws 2015-01-27 22:00:20 UTC
(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
Comment 49 Commit Notification 2015-01-28 12:50:36 UTC
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.
Comment 50 Andras Timar 2015-01-28 13:22:58 UTC
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.
Comment 51 jflash 2015-02-03 20:40:40 UTC
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.
Comment 52 Cor Nouws 2015-02-03 21:27:34 UTC
(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.
Comment 53 Cor Nouws 2015-02-04 11:12:56 UTC
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.
Comment 54 Matthew Francis 2015-02-06 00:29:56 UTC
*** Bug 89157 has been marked as a duplicate of this bug. ***
Comment 55 Kumāra 2015-02-06 06:32:13 UTC
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... )
Comment 56 Kumāra 2015-02-06 06:35:29 UTC
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.
Comment 57 chris.hoe 2015-02-10 14:07:40 UTC
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!
Comment 58 un5412 2015-03-09 18:20:57 UTC
Can confirm this bug for all my LO versions starting from 4.3.0 on Windows 7/8 platforms
Comment 59 chris.hoe 2015-03-31 09:39:02 UTC
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!!!
Comment 60 chris.hoe 2015-03-31 11:05:32 UTC
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. :-(
Comment 61 Winfried Donkers (retired) 2015-03-31 11:34:36 UTC
(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
Comment 62 Joel Madero 2015-03-31 16:36:28 UTC
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/
Comment 63 Cor Nouws 2015-03-31 19:11:30 UTC
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
Comment 64 Joel Madero 2015-03-31 19:30:03 UTC
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
Comment 65 Cor Nouws 2015-03-31 20:32:23 UTC
(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..)
Comment 66 V Stuart Foote 2015-04-01 02:09:14 UTC
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.
Comment 67 V Stuart Foote 2015-04-01 02:45:40 UTC
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.
Comment 68 Cor Nouws 2015-04-01 07:51:29 UTC
(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.
Comment 69 chris.hoe 2015-04-01 10:14:44 UTC
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!
Comment 70 Kumāra 2015-04-03 03:23:02 UTC
(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.)
Comment 71 Kumāra 2015-04-03 03:26:20 UTC
In the case of a successful backport, would it be indicated here?
Comment 72 Joel Madero 2015-04-03 03:36:04 UTC
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 :)
Comment 73 Commit Notification 2015-04-14 19:59:58 UTC
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.
Comment 74 Kumāra 2015-04-15 02:47:08 UTC
(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").
Comment 75 Pedro 2015-04-16 11:28:46 UTC
Confirmed fixed in Version: 4.4.3.1
Build ID: b2f347f2ac68821efc00b6f1793cda90af748118

under Windows XP Pro x86 SP3

Thank you Kendy!
Comment 76 Kim Bastin 2015-04-16 13:54:04 UTC
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.
Comment 77 V Stuart Foote 2015-04-16 14:20:15 UTC
(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
Comment 78 V Stuart Foote 2015-04-16 14:26:00 UTC
(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.
Comment 79 Commit Notification 2015-04-16 21:09:45 UTC
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.
Comment 80 Kim Bastin 2015-04-17 01:18:43 UTC
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.
Comment 81 V Stuart Foote 2015-04-17 03:42:16 UTC
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
Comment 82 Cor Nouws 2015-04-26 19:40:10 UTC
Already enjoying for more then a week the great pleasure that this has been fixed.

Thanks all that helped :) !
Comment 83 richard_g 2015-05-04 12:37:03 UTC
At least, problem solved in Libre Office 4.4.3.2 !

Thank you very much, Libre Office team and others !!!
Comment 84 Peter Roelofsen 2015-05-25 14:44:34 UTC
Still present in 5.0.0.0.Beta1 Build ID: 0a16c3dda4150008d9be6f24cbd15ac198d116d3
Comment 85 Peter Roelofsen 2015-05-25 16:18:02 UTC
Correction to my previous: it works after all, after I entered my name in the Personal data fields. :8
Comment 86 Cor Nouws 2015-05-25 18:13:43 UTC
works fine for me in 5.0.0beta1.
With given name and sir name added in Tools > Options > LibreOffice ... of course.
Comment 87 Cor Nouws 2015-05-25 18:14:53 UTC
ah, seeing your latter comment only now - fifo handling here ;)
Comment 88 Robinson Tryon (qubit) 2015-12-17 08:25:16 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]