Description: copying text to clipboard changes the current search target Steps to Reproduce: 1. find something 2. copy some text to the clipboard 3. press ^F Actual Results: find field is focused and contains the recently copied text from the clipboard Expected Results: find field should've contained the previously used search string Reproducible: Always User Profile Reset: No Additional Info: I have to use a docked find toolbar until Bug 116563 is fixed User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3
please disregard the comment about Bug 116563 - it is already fixed and this bug is reproducible with both docked and undocked finds
I confirm the behaviour, but I'm not sure, if it is a bug or not. I would expect the result you expect, but the actual behaviour also might be an easy way to search for a specific phrase in a text. So let's ask the experts from the design-team.
(In reply to Dieter Praas from comment #2) > the actual behaviour also might be an easy way to search for a specific phrase in a text. Actually my initial description is incorrect, ^F doesn't use the text from the clipboard, it uses the currently selected text even if it is not copied to the clipboard. So why should I be looking for the text I already found?
(In reply to lvm from comment #3) > So why should I be looking for the text I already found? It might be useful, if you have a text of (for example) more than 10 pages and you want to now where you have used this specific expression.
Initializing the search with the current selection is standard behavior. Try for example with your Internet browser. Dieter explained the reason for it, and to turn that around, why would you select something and still search for previous terms?
Tried it with my browser (seamonkey) - nothing like that, old search string is retained. Tried it with chrome - same result. For me the standard behaviour would be to restrict the search area to selection. BTW calc can do it, only for S&R though. It can also happen that I selected something previously for some other reason unrelated to searching - are you suggesting that I should clear the selection before every search? But chances that someone would want to search for a selection several pages long are close to zero.
Okay, Chrome(ium) is very special with search. I was talking about Firefox but also Kate or QtCreator. While your workflow is also an option I assume most users prefer how it's currently implemented. Is it worth the effort to implement both variants with an user choice? I don't think so. As you reverted the status I will not change it back. Input from UX has been given.
Kate indeed behaves this way but there is a trick you might want to borrow: it won't use the selection as a search target if exceeds a certain size while writer will cheerfully try to copy anything up to the whole document into the single line search field. Just for the fun of it, tried pressing ^F with a 170,000 line selection - you should try it too to see how good the current concept is. I am sorry to say that, but it looks like you are making choices in favour of casual users and 3-line test cases. Also, for the most google or MS solutions are a de-facto standard.
(In reply to lvm from comment #8) > Kate indeed behaves this way but there is a trick you might want to borrow: > it won't use the selection as a search target if exceeds a certain size > while writer will cheerfully try to copy anything up to the whole document > into the single line search field. Just for the fun of it, tried pressing ^F > with a 170,000 line selection - you should try it too to see how good the > current concept is. Indeed, this restriction makes sense. But would be a different topic.
> So why should I be looking for the text I already found? Because you need to find the next occurrence. For me that is the expected behavior and it works as designed. So there is no bug. From my point of view Chrome/Chromium behavior is defective because you need more action to find something. Closing as NotABug again. You can open an enhancement request but you should argue carefully to convince why changing the current behavior is better than keep it. Best regards. JBF
(In reply to Jean-Baptiste Faure from comment #10) > > So why should I be looking for the text I already found? > Because you need to find the next occurrence. > Don't you see there is no logic in your words? If I am looking for the next occurrence, the target I am looking for is already in the search box. This is exactly why this behaviour is a poor UX choice and a bug - because selecting anything unexpectedly breaks searching for the next target. And because is breaks libreoffice completely if the selection is large enough - all open windows of all types, not just the one writer window, but that's secondary. Ok, I'll make it a feature, maybe even optional, but despite everything said here I still fail to see real-world use for the current behaviour, only harm and annoyance.
You can't confirm your own bug report.
It was confirmed by Dieter Praas in comment #2 and it is not longer a bug but an enhancement.
Heiko, can design-team decide about this proposal for an enhancement or about the proposal for restriction you mentioned in comment 9?
(In reply to lvm from comment #13) > It was confirmed by Dieter Praas in comment #2 and it is not longer a bug > but an enhancement. The behavior is confirmed in comment #2, not that this behavior is a bug. Heiko and me think that it is not a bug but the expected behavior. For me changing the current behavior is not an enhancement, that is create a regression. Best regards. JBF
Putting it back to UNCONFIRMED until a final decision is taken...
Can not confirm, current UI is consistent and correct. With Ctrl+F Findbar *enabled* and present in the UI, a selection/copy from text does not change the current find target! The Find bar retains original entry and Find Previous/Find Next/Find All buttons continue with that value. Only if the Findbar has been *closed* does a new selection/copy from text replace the prior search. And with no ensuing selection, the prior find target is used. This UI makes functional sense and is consistent. If you don't want/need to retain the find target close the Findbar--if you want to retain it to be able to navigate through text leave it open. Changing this would impose a regression for users used to working with the Findbar. Otherwise the issue of placing an arbitrary limit on the size of the string held in the Findbar is reasonable--maybe ~256 characters?
Input from Stuart at comment 17 and Cor who agreed with comment 9 comply with WONTFIX.
(In reply to Heiko Tietze from comment #18) > Input from Stuart at comment 17 and Cor who agreed with comment 9 comply > with WONTFIX. So I changed the status to RESOLVED WONTFIX. Heiko, please correct it, if I misunderstood something.
(In reply to V Stuart Foote from comment #17) > This UI makes functional sense and is consistent. If you don't want/need to > retain the find target close the Findbar--if you want to retain it to be > able to navigate through text leave it open. It is true only for the docked findbar, undocked findbar is always closed after use: you find the place you where looking for and press escape to close the find window and return to the main editing window. If you want to continue searching you press ^F to reopen it again, and it should retain the current search target regardless of what has happened in the editing window. Second, as always > Changing this would impose a regression for users used to working with the > Findbar. As always, if it affects existing functionality the behaviour should be controlled by an option satisfying both sides. Although personally I doubt that there are many users of this feature because until now no one has provided a reasonable workflow apart from 'searching for the text already found' which is very weak. Now if it used the clipboard contents rather than the current selection in the focused window it really might have been useful.
(In reply to lvm from comment #20) > (In reply to V Stuart Foote from comment #17) > > > This UI makes functional sense and is consistent. If you don't want/need to > > retain the find target close the Findbar--if you want to retain it to be > > able to navigate through text leave it open. > It is true only for the docked findbar, undocked findbar is always closed > after use: you find the place you where looking for and press escape to > close the find window and return to the main editing window. If you want to > continue searching you press ^F to reopen it again, and it should retain the > current search target regardless of what has happened in the editing window. No, by design 'Closing' and reopening the Find bar reinitializes it--either Docked or Undocked. If you need to retain the search string, do not close it! Meaning, rather than <Esc> to close the undocked Find bar, a mouse click, text selection, or cursor movement places cursor focus back onto document canvas. Using a current selection as find target on launch remains correct and expected behavior. Also expected on launch, with no selection made from canvas, the prior find targets are available as a droplist stack for reuse. And that stack is persistent until LibreOffice is closed. This behavior is correct when 'Opening' or 'Reopening' the find bar. "Enhancement" suggested is not necessary, preloading the last find target rather than a current selection would break what is already functional. => WONTFIX Setting a limit on the size of a current selection that would/could be used as a find target probably should be done.
> Meaning, rather than <Esc> to close the undocked Find bar, a mouse click, > text selection, or cursor movement places cursor focus back onto document > canvas. > Excuse me, how one can move cursor or select text in the main window when find bar has the focus and intercepts all keystrokes? As for taking hands off keyboard and using a mouse, it is just inefficient - as well as keeping the find bar floating around in case I might want to keep searching for the same target. The proper way to use the find window is to use it and close it or even close it automatically upon find e.g. like in mcedit. More importantly so far no one has produced a viable workflow for using selection as the new search target. Why are you so sure that anyone uses it rather than treating it as a mild annoyance?
(In reply to lvm from comment #22) > > > Excuse me, how one can move cursor or select text in the main window when > find bar has the focus and intercepts all keystrokes? As for taking hands > off keyboard and using a mouse, it is just inefficient - as well as keeping > the find bar floating around in case I might want to keep searching for the > same target. For keyboard navigation F6, F10, or <Ctrl>+<F6>, coupled with <Ctrl>+F allow you to move between GUI elements and Findbar witout use of mouse. >... The proper way to use the find window is to use it and close it > or even close it automatically upon find e.g. like in mcedit. > And again, that is simply not a valid assertion, and is not how our Find bar (or any Toolbar) is designed to work in the OOo, AOO, or LO GUI. The Find toolbar object behaves like any other toolbar. I've routed this back for UX-advise, but IMHO remains undesirable. => WONTFIX
> And again, that is simply not a valid assertion, and is not how our Find bar > (or any Toolbar) is designed to work in the OOo, AOO, or LO GUI. The Find > toolbar object behaves like any other toolbar. > As far as I remember at first there was no find toolbar, only the modal find dialogue which behaved in a way all find dialogues behaved: you opened it to search and closed it upon find. Then someone created a find toolbar as an alternative way of searching. Then someone decided to optimize and create a common component using the find toolbar as the base. The intent was good, the implementation was not, and enforcing find toolbar behaviour on the find dialogue which is now became undocked find toolbar created all sorts of unwanted side effects in all components e.g. Bug 102506. I am afraid your statement is invalid, you cannot say that 'this is the way toolbar works'. Undocked find is not a toolbar, it replaced the find dialogue and should behave like one even if it is based on the toolbar.
(In reply to lvm from comment #22) > Excuse me, how one can move cursor or select text in the main window when > find bar has the focus and intercepts all keystrokes?... Would have been good to put this use case at the beginning. Your enhancement proposal might be one solution for your problem but isn't how LibreOffice works and has drawbacks for other use cases. The shortcut is ctrl+F6 to go back to the document, see comment 23.