Description: It seems to be a one of the existing issues that the program does not return you to the place of last activity So suppose you edit the fifth line of the 8th page, close the app, open the document, and you have to get back there all by yourself without any automatic help. That seems to be pretty hurtful, as the app always returns you to the first page of any document What if there was a keyboard combination that returns you to the place of last activity? So the app should memorise the last activity before app closure and get the user there Steps to Reproduce: 1.Edit a latter page in a document 2. Close the app 3. Open the document Actual Results: It returns you to the first page Expected Results: Ability to get to the place of last activity without memorising it Reproducible: Always User Profile Reset: No Additional Info: None
You need to have some field covered in Menu>Tools>Options>LibreOffice>User Data>Address, so LibreOffice can identify a location for the user. Please paste here the information on Menu/Help/About LibreOffice (There is an icon to copy)
(In reply to m_a_riosv from comment #1) > You need to have some field covered in Menu>Tools>Options>LibreOffice>User > Data>Address, so LibreOffice can identify a location for the user. > > Please paste here the information on Menu/Help/About LibreOffice (There is > an icon to copy) That's the reason I'm averse to verbal explanations of bugs - no one understands anything. That's my lack of skill at such explanations Videos might be harder to watch, but you end up with no confusion and precise understanding of the issue - and I believe it's more important. I always knew that nobody would've understood me if I didn't show videos Please watch https://drive.google.com/file/d/1WJFuVOJ2lU1c0c3UjWNTOA4fjERIMIUR/view?usp=sharing
Go to Tools -> Options -> User Data and make some entry in the fields there. Then Apply and OK. Restart LibreOffice, open, edit the 5th line of the 8th page, and save your document. The start position is recorded to your user profile. Close LibreOffice. Open the document from the same os/DE user. Where do you find the view port and cursor. The NEEDINFO is to you to provide details of you installation. Tools -> Help -> About LibreOffice, use the provided button to copy details. Paste to this BZ issue.
(In reply to V Stuart Foote from comment #3) > Go to Tools -> Options -> User Data and make some entry in the fields there. > > Then Apply and OK. > > Restart LibreOffice, open, edit the 5th line of the 8th page, and save your > document. The start position is recorded to your user profile. > > Close LibreOffice. > > Open the document from the same os/DE user. > > Where do you find the view port and cursor. > > The NEEDINFO is to you to provide details of you installation. > Tools -> Help -> About LibreOffice, use the provided button to copy details. > Paste to this BZ issue. What did I do wrong? https://drive.google.com/file/d/13TdN8_zNuRkfJIL1iISxGyBmRhgtbLO9/view?usp=sharing
(In reply to Danat from comment #4) > > The NEEDINFO is to you to provide details of you installation. > > Tools -> Help -> About LibreOffice, use the provided button to copy details. > > Paste to this BZ issue. > > What did I do wrong? > > https://drive.google.com/file/d/13TdN8_zNuRkfJIL1iISxGyBmRhgtbLO9/ > view?usp=sharing Your user info fields seem fine. Although we still have no idea what build of LibreOffice you are using. Please copy paste the Help -> About details! On opening, does a <Shift>+<F5> position Edit cursor "View Port" to the last edited on save? Only thing that I notice is you are saving the file as OOXML "Дokymeht Microsoft Word.docx". It is considered an external format and passes the document through a filter on saving and opening. Please test if using LibreOffice native ODF file format behaves in positioning the edit "view port" and text cursor position when saving closing LibreOffice and reopening. Also check the <Shfit>+<F5> behavior. Generally, if you require OOXML .docx--you should save *copies* in that format. But keep and work on your documents in ODF formats for full feature support.
(In reply to V Stuart Foote from comment #5) > (In reply to Danat from comment #4) > > > > The NEEDINFO is to you to provide details of you installation. > > > Tools -> Help -> About LibreOffice, use the provided button to copy details. > > > Paste to this BZ issue. > > > > What did I do wrong? > > > > https://drive.google.com/file/d/13TdN8_zNuRkfJIL1iISxGyBmRhgtbLO9/ > > view?usp=sharing > > Your user info fields seem fine. Although we still have no idea what build > of LibreOffice you are using. Please copy paste the Help -> About details! > > On opening, does a <Shift>+<F5> position Edit cursor "View Port" to the last > edited on save? > > Only thing that I notice is you are saving the file as OOXML "Дokymeht > Microsoft Word.docx". It is considered an external format and passes the > document through a filter on saving and opening. > > Please test if using LibreOffice native ODF file format behaves in > positioning the edit "view port" and text cursor position when saving > closing LibreOffice and reopening. Also check the <Shfit>+<F5> behavior. > > Generally, if you require OOXML .docx--you should save *copies* in that > format. But keep and work on your documents in ODF formats for full feature > support. shift+f5 works in Word but not in LibreOffice https://youtu.be/0ODfrH87qiU My version https://drive.google.com/file/d/1huAGQHHWz3fYQXGeQ_a3Aw04E_Fg0F-2/view?usp=sharing It seems like this feature is just absent in LibreOffice. Please add it
From OP comment 6: Version: 25.8.2.2 Build: d401f2107ccab8f924a8e2df4... Environment: CPU threads: 8; OS: Windows 11 x86_64 (build 26200) User Interface: UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Misc: Calc: threaded Can not confirm. Works for me...
(In reply to V Stuart Foote from comment #7) > From OP comment 6: > > Version: 25.8.2.2 > Build: d401f2107ccab8f924a8e2df4... > Environment: CPU threads: 8; OS: Windows 11 x86_64 > (build 26200) > User Interface: UI render: Skia/Raster; VCL: win > Locale: ru-RU (ru_RU); UI: en-US > Misc: Calc: threaded > > Can not confirm. Works for me... I can see that LibreOffice does indeed have this shortcut in its user guide, but it won't do anything on my laptop ctrl+f5 works but shift+f5 does not Please have a look https://drive.google.com/file/d/1KPFVPXdI5p3eOq1VKk0S2TpNFrTp9R3x/view?usp=sharing
*** Bug 169164 has been marked as a duplicate of this bug. ***
Have you tested if the shortcut is defined in Menu>Tools>Customize>Keyboard?
(In reply to m_a_riosv from comment #10) > Have you tested if the shortcut is defined in Menu>Tools>Customize>Keyboard? There is a long list of functions. Which one to choose? https://drive.google.com/file/d/1QOwxs-DLRqDoo9YaWZznaKE7GadnBH0x/view?usp=sharing
(In reply to m_a_riosv from comment #1) > You need to have some field covered in Menu>Tools>Options>LibreOffice>User > Data>Address, so LibreOffice can identify a location for the user. > > Please paste here the information on Menu/Help/About LibreOffice (There is > an icon to copy) I seem to have found out why it's unworking You use odt and I use docx At docx, it does not work So what is your takeaway from that? Is it a bug? https://drive.google.com/file/d/127DIa6dn9xfjArkxvYnRXWlHnabhjRCd/view?usp=sharing
(In reply to V Stuart Foote from comment #7) > From OP comment 6: > > Version: 25.8.2.2 > Build: d401f2107ccab8f924a8e2df4... > Environment: CPU threads: 8; OS: Windows 11 x86_64 > (build 26200) > User Interface: UI render: Skia/Raster; VCL: win > Locale: ru-RU (ru_RU); UI: en-US > Misc: Calc: threaded > > Can not confirm. Works for me... I seem to have found out why it's unworking You use odt and I use docx At docx, it does not work So what is your takeaway from that? Is it a bug? https://drive.google.com/file/d/127DIa6dn9xfjArkxvYnRXWlHnabhjRCd/view?usp=sharing
(In reply to Danat from comment #13) > ... > You use odt and I use docx > > At docx, it does not work > > So what is your takeaway from that? Is it a bug? As I'd noted in comment 5, unclear as to being a bug. I don't own MS Word nor create OOXML documents. Recent work on bug 41777 might improve things (it touches the WriteUserDataSequence() in uibase/uiview/view.cxx). @Mike K. any insight for as to ViewFrame repositioning on reopening an OOXML document? Is this supported in ODF .ODT documents only, so => NAB?
(In reply to V Stuart Foote from comment #14) > @Mike K. any insight for as to ViewFrame repositioning on reopening an OOXML > document? Is this supported in ODF .ODT documents only, so => NAB? Bug 140147 comment 81.
(In reply to Mike Kaganski from comment #15) > (In reply to V Stuart Foote from comment #14) > > @Mike K. any insight for as to ViewFrame repositioning on reopening an OOXML > > document? Is this supported in ODF .ODT documents only, so => NAB? > > Bug 140147 comment 81. OMG, I am getting senile! And yes, you'd suggested we move away from the ViewTop & ViewLeft based cursor repositioning in your bug 141586 Seems like for interoperability that using a static 'w:Name="_GoBack"' bookmark remains viable for OOXML import/export--not deprecated. While at ODF 1.4 the 19.841.4 <text:bookmark> could use the same name for our own UserData match and reposition. Revisit Justin's simple "_GoBack" bookmark export of a GetCursor() mark as for => WF bug 112740 -- https://gerrit.libreoffice.org/c/core/+/136408/1 needed for OOXML support, or better to do a more complete refactoring--and maybe integrate into the SB Navigator 'Recency' 'Reminder' and 'Bookmark' stacks.
(In reply to V Stuart Foote from comment #14) > (In reply to Danat from comment #13) > > ... > > You use odt and I use docx > > > > At docx, it does not work > > > > So what is your takeaway from that? Is it a bug? > > As I'd noted in comment 5, unclear as to being a bug. > > I don't own MS Word nor create OOXML documents. > > Recent work on bug 41777 might improve things (it touches the > WriteUserDataSequence() in uibase/uiview/view.cxx). > > > @Mike K. any insight for as to ViewFrame repositioning on reopening an OOXML > document? Is this supported in ODF .ODT documents only, so => NAB? So it's not a bug because you don't create docx files? What about people who do? I thought thoroughly and couldn't find an explanation as to why you marked this bug as notabug. You didn't give any reason for that You didn't even attempt to reproduce it with a docx file
(In reply to Mike Kaganski from comment #15) > (In reply to V Stuart Foote from comment #14) > > @Mike K. any insight for as to ViewFrame repositioning on reopening an OOXML > > document? Is this supported in ODF .ODT documents only, so => NAB? > > Bug 140147 comment 81. These are your words in the linked comment. Do you consider this to be a bug? What is the rationale behind giving certain features to odt and not other formats? "In LibreOffice (and in OpenOffice), there was *never* a feature of restoring the editing position *in foreign documents*. DOCX is completely unrelated to the issue discussed here."
As noted, OOXML .docx is not a core format. Features of LibreOffice are built against OASIS Open Document Format for Office Applications. In this case <Shift>+<F5> has meaning for ODF Document (.odt). OOXML support is via export/import filters that have no requirement to be 100% fidelity. The "_GoBack" named bookmark that OOXML uses was never implemented for LibreOffice filter import--it is simply dropped on import and not written on export. As you've found the feature works as implemented for ODF Document (.odt) format. Discussion around moving away from a reopen cursor position based on a described viewport to a persistent bookmark based opening position is the see also bug 141586. If the devs decide to implement something along those lines, it could likely be refined to implement support for the OOXML flavor of a bookmark. And implementing something for OOXML would be a "Feature Request", and this becomes "Not a Bug" as is, or morphs to a feature request. But then would likely be resolved a duplicate of bug 141586 at that point. Hope that makes sense. Resolving again => NAB, it works as designed.
Sure, an enhancement. Implement for OOXML interoperability in addition to work needed on bug 141586