[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

Heiko Tietze  changed:

   What|Removed |Added

 CC|libreoffice-ux-advise@lists |
   |.freedesktop.org|
   Keywords|needsUXEval |

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

--- Comment #25 from Heiko Tietze  ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

--- Comment #24 from l...@royal.net ---
> 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

V Stuart Foote  changed:

   What|Removed |Added

 CC||libreoffice-ux-advise@lists
   ||.freedesktop.org
   Keywords||needsUXEval

--- Comment #23 from V Stuart Foote  ---
(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 +, coupled with +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

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

--- Comment #22 from l...@royal.net ---
> Meaning, rather than  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?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

V Stuart Foote  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #21 from V Stuart Foote  ---
(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  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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

l...@royal.net changed:

   What|Removed |Added

 Resolution|WONTFIX |---
 Status|RESOLVED|UNCONFIRMED

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

--- Comment #20 from l...@royal.net ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

Dieter Praas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #19 from Dieter Praas  ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

--- Comment #18 from Heiko Tietze  ---
Input from Stuart at comment 17 and Cor who agreed with comment 9 comply with
WONTFIX.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

V Stuart Foote  changed:

   What|Removed |Added

 CC||vstuart.fo...@utsa.edu

--- Comment #17 from V Stuart Foote  ---
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?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

Xisco Faulí  changed:

   What|Removed |Added

 Ever confirmed|1   |0
 CC||xiscofa...@libreoffice.org
 Status|NEW |UNCONFIRMED

--- Comment #16 from Xisco Faulí  ---
Putting it back to UNCONFIRMED until a final decision is taken...

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

--- Comment #15 from Jean-Baptiste Faure  ---
(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

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

--- Comment #14 from Dieter Praas  ---
Heiko, can design-team decide about this proposal for an enhancement or about
the proposal for restriction you mentioned in comment 9?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

l...@royal.net changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|NOTABUG |---

--- Comment #13 from l...@royal.net ---
It was confirmed by Dieter Praas in comment #2 and it is not longer a bug but
an enhancement.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

Jean-Baptiste Faure  changed:

   What|Removed |Added

 Resolution|--- |NOTABUG
 Status|NEW |RESOLVED

--- Comment #12 from Jean-Baptiste Faure  ---
You can't confirm your own bug report.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

l...@royal.net changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Resolution|NOTABUG |---
 Ever confirmed|0   |1
 Status|RESOLVED|NEW

--- Comment #11 from l...@royal.net ---
(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 are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

Jean-Baptiste Faure  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |NOTABUG
 CC||jbfa...@libreoffice.org

--- Comment #10 from Jean-Baptiste Faure  ---
>  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

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

--- Comment #9 from Heiko Tietze  ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

--- Comment #8 from l...@royal.net ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

--- Comment #7 from Heiko Tietze  ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

l...@royal.net changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|NOTABUG |---

--- Comment #6 from l...@royal.net ---
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 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

Heiko Tietze  changed:

   What|Removed |Added

   Keywords|needsUXEval |
 Status|UNCONFIRMED |RESOLVED
 CC|libreoffice-ux-advise@lists |tietze.he...@gmail.com
   |.freedesktop.org|
 Resolution|--- |NOTABUG

--- Comment #5 from Heiko Tietze  ---
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?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

[Libreoffice-bugs] [Bug 117755] selecting text changes the current search target

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=117755

l...@royal.net changed:

   What|Removed |Added

Summary|copying text to clipboard   |selecting text changes the
   |changes the current search  |current search target
   |target  |

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs