Bug 146648 - Find and Replace dialog changes position when reopened (gtk3)
Summary: Find and Replace dialog changes position when reopened (gtk3)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All Linux (All)
: medium minor
Assignee: Jim Raykowski
URL:
Whiteboard: target:7.4.0
Keywords:
Depends on:
Blocks: Find-Search Dialog-Remember-Settings
  Show dependency treegraph
 
Reported: 2022-01-08 11:32 UTC by R. Green
Modified: 2022-04-09 09:01 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description R. Green 2022-01-08 11:32:26 UTC
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.
Comment 1 V Stuart Foote 2022-01-08 15:28:34 UTC
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.
Comment 2 R. Green 2022-01-08 18:23:17 UTC
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.)
Comment 3 V Stuart Foote 2022-01-08 19:09:20 UTC
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.
Comment 4 Daveo 2022-01-08 19:30:53 UTC
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?
Comment 5 R. Green 2022-01-09 10:59:33 UTC
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.
Comment 6 V Stuart Foote 2022-01-09 14:48:05 UTC
(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
Comment 7 Daveo 2022-01-09 14:57:07 UTC
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"?
Comment 8 Heiko Tietze 2022-01-10 08:18:43 UTC
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.
Comment 9 Jim Raykowski 2022-01-16 03:00:57 UTC
Here is a few days of fun!
https://gerrit.libreoffice.org/c/core/+/128473
Comment 10 Commit Notification 2022-01-26 13:50:19 UTC
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.
Comment 11 Commit Notification 2022-01-26 15:05:57 UTC
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.
Comment 12 Commit Notification 2022-01-27 14:04:41 UTC
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.