Version: 7.1.5.2 / LibreOffice Community Build ID: 85f04e9f809797b8199d13c421bd8a2b025d52b5 CPU threads: 2; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-GB Calc: threaded Open any Writer document. Open "Find & Replace" (Ctrl H) and move it to a new position, then close, and reopen again. EXPECTED RESULT: At least in the same session, "Find & Replace" should open in the last set user position. ACTUAL RESULT: "Find & Replace" opens in the default position.
Positioning sense of Find & Replace (and I'd assume the Find Bar) is to follow the edit cursor. You can prove that with subsequent launch of the dialog using either the 'Find Next' or 'Find Previous'. Meaning the edit cursor is "the last set user position" and the anchor for Find & Replace "position" within the current document. Believe even the 'Find All' or 'Replace All' is relative to the current edit cursor. Not clear any other behavior would make sense. Could you please restate your use case and STR, thanks.
We seem to be at cross purposes. I'm referring only to the position of the F&R dialogue in relation to the program window, i.e. how far to the left or right or up or down it is. Currently it always appears in the same position on the screen. If you move it to the side (to prevent it obscuring the document and other informational features) and close the dialogue, on reopening it reappears in the default position. It would be useful if I could move it to the optimum position and keep it there no matter how many times I open and close it – at least for the duration of the session. (I have no complaints about the search behaviour, i.e. how terms appear in the FIND field etc.)
OK, my fault. I'm so used to reading between the lines for issue intake I was over thinking it. However, can not confirm on Version: 7.2.5.1 (x64) / LibreOffice Community Build ID: 6d497ff5e83a906a307eb25cce314d40c0b8624f CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded WFM with each opening of the Find & Replace dialog, current session or on new LO launch, will be where it had last been moved to. On Windows at least, its positioning is on the full desktop--the LO application frame position and sizing has no impact.
The results of my checks with Windows 10 and the "official" LibreOffice Linux installations are exactly the same as reported by V Stuart Foote in comment 3. Are you running a distro provided edition?
I see what's happening now. F&R follows last user position on launching IF it was last closed with the "Close" button. But IF you close it with the X (cross icon) instead, it next opens in the default position. Pressing [ESC] leads to the same issue. AFAIK, the launch behaviour should be the same (i.e. last user position) no matter how you last closed the F&R window.
(In reply to R. Green from comment #5) > I see what's happening now. F&R follows last user position on launching IF > it was last closed with the "Close" button. But IF you close it with the X > (cross icon) instead, it next opens in the default position. Pressing [ESC] > leads to the same issue. > > AFAIK, the launch behaviour should be the same (i.e. last user position) no > matter how you last closed the F&R window. On Windows builds can not confirm, it makes no difference on how the dialog is dismissed: 'Close' button, <Esc>, or the frames CSD 'X' button
CONFIRMED with the "official" LibreOffice 7.2.5.2 Linux installation. Closing the dialog's close button retains the dialog's last position, reopening the dialog after closing the dialog with ESC key or the title bar close button positions the dialog center screen Unable to replicate the issue with LO 7.2.5.2 under Windows 10. Maybe an "Easy Hack"?
We neither store size nor position, yet. Position is a bit more tricky than size since users could move a dialog to a second screen which might become detached later making the dialog not accessible. Ideally we check this condition but at minimum we should remember the position during the running session.
Here is a few days of fun! https://gerrit.libreoffice.org/c/core/+/128473
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/be34fe06751609382b5a650d481cf4be2484c6f8 Related: tdf#146648 store last known position when visible to return later It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3bf0f94b373037fc662e617f936b57f9f317b142 tdf#146648 make find and replace dialog reopen at last position It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5d388b94735e34ba445d65e1d5030a646aad7dbe Related: tdf#146648 let SetWindowState size trump the initial layout pref size It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.