Description: Find & Replace dialog should auto-move to expose found string. Steps to Reproduce: 1. Open a document in which one character occurs often. Since I had prepared a long text in a text editor and copied it into LO Writer, I had a straight quotation mark I wanted to replace with a curved ("smart") apostrophe. 2. Ctrl-h, for Find & Replace. 3. Plan to replace that character with something else (I suppose this will apply even if you replace it with the same character). 4. Drag the Find & Replace dialog somewhere. I do not know if the feature exists unless you have dragged it manually, so drag it. While it is probably best to drag it far down into the right corner, that hides so little that it might defeat seeing the problem. 5. Use Find Next. (I did not try Find Previous.) 6. Do not Replace All. Instead, Replace one string at a time. 7. Since the string occurs frequently, chances are it will sometimes be behind the dialog. If you don't see it in the window, drag the dialog and see if that exposes the found string. Actual Results: A found string that happens to be behind the dialog is not visible. Expected Results: The dialog moves aside under its own power to expose a found string behind it. Reproducible: Always User Profile Reset: No Additional Info: The problem is in version 6.3.4.2.0+ (build ID 6.3.4.2-2.fc31). I'm not prepared to install a newer or unstable verion. This is a usability issue for nongeeks who work quickly. They can learn to drag the dialog but likely would prefer it do it automatically. LO's safe mode appears irrelevant. I don't have an OpenGL setting.
I can't confirm it with Version: 6.3.4.2 (x64) Build-ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded Text moves, so search results are never behind the dialog. So it works like I would expect. So the dialog doesn't jump like you expect. But I wouldn't prefer this, because in this case, you always have to move cursor, to click within the dialog. Perhaps you can give it a try in save mode?
I'm confused by your comment. You say text "moves", but it does not. You say "search results are never behind the dialog", but what the Find function highlights can be behind the dialog, depending on where the dialog is relative to the document, and sometimes the highlighted text is hidden by the dialog. I assume your dialog does not jump aside, so it has to hide highlights under some arrangements of document content and the dialog. If the next found string is behind the dialog and so the dialog were to auto-move so you could see the string, you could still click within the dialog. That's because the auto-move would be done in an instant and then the dialog would be stationary, and while it's stationary is when you could click in it. You could position the dialog so that it almost never hides anything, by dragging it to where only a small corner of the dialog is visible, but then you can't click in it, because most of it would be beyond the window. Alt-keys would work, but not clicking. Safe Mode, which I've now tried, didn't change the effect I described. I didn't drag the dialog and it still hid found strings (this time, "e") without auto-moving. This is from the About dialog: Version: 6.3.4.2.0+ Build ID: 6.3.4.2-2.fc31 CPU threads: 2; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded Your build ID is different. So's the OS. Maybe those explain the difference in our experiences, especially the OS. I'm also not sure that this should be considered as a bug (albeit a minor bug) rather than as a feature request, which is how I originally reported it. And you don't seem to think it is a bug. Should we change that back?
(In reply to Nick Levinson from comment #2) > I'm confused by your comment. > > You say text "moves", but it does not. I believe that it doesn't move in your case, but believe, that it does move in my case (I assume, that you also have some line of text above the dialog window). > Your build ID is different. So's the OS. Maybe those explain the difference > in our experiences, especially the OS. Yes, that could be an explanation. > I'm also not sure that this should be considered as a bug (albeit a minor > bug) rather than as a feature request, which is how I originally reported > it. And you don't seem to think it is a bug. Should we change that back? If the behaviour doesn't occur in my version, but in your version, I would treat it as a bug.
So how should the dialog behave, if you are zoomed in very much, are replacing a long string spanning many lines etc.? In these cases you might not have anywhere to move the dialog.
Works perfectly for me. Test case: dt+f3 (adds dummy text), copy/paste the paragraph a couple of times. Picked a word and used Find Next. Where the canvas scrolls depends on the position of the F&R dialog. The citation is never behind. But my screen is rather large, maybe you work on a small notebook. Version: 6.3.6.2 Build ID: 6.3.6-1 CPU threads: 8; OS: Linux 5.6; UI render: GL; VCL: kde5; Locale: de-DE (en_US.UTF-8); UI-Language: en-US Calc: threaded
Not confirmed, no further replies. Please reopen in case we missed something.