Bug 49706 - Find Toolbar does not retrieve text from clipboard
Summary: Find Toolbar does not retrieve text from clipboard
Status: RESOLVED DUPLICATE of bug 37791
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
3.4.4 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-09 13:41 UTC by Andras Timar
Modified: 2012-08-17 15:53 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andras Timar 2012-05-09 13:41:47 UTC
It is a very frequent use case, when I have a word to search for, I copy it with Ctrl+C, I press Ctrl+F and ... it is not in the edit box of Find Toolbar, I have to press Ctrl+V. It works with the old Find and Replace (Ctrl+H) dialog.
Comment 1 Roman Eisele 2012-05-11 08:26:44 UTC
REPRODUCIBLE with LibreOffice 3.5.3.2 (Build-ID: 235ab8a-3802056-4a8fed3-2d66ea8-e241b80), German langpack installed, on MacOS X 10.6.8 German UI.

Steps:
1) Copy some text to the clipboard.
2) Start LibreOffice.
3) Open a Writer document (.odt)
4) Press Cmd+F (= Ctrl+F for Windows): Find.
5) The Find toolbar appears and gets the focus; the curser is blinking inside the find edit field.
6) Press Cmd+V (= Ctrl+V for Windows): Paste.

Expected behaviour: The text copied in step 1) is pasted into the Find edit field, because it has the focus.

Acutal behaviour: The text copied in step 1) is pasted somewhere into the text of the Writer document.

Not terrible, but irritating, especially for 'power users'.
Comment 2 Roman Eisele 2012-05-11 08:33:53 UTC
Already REPRODUCIBLE with LibreOffice 3.4.4, German langpack installed, on MacOS X
10.6.8 German UI. Therefore adapting the 'Version' field.

Probably present since the implementation of the new Find toolbar in the 3.4 development process, but I don't have a 3.4.x installation older than 3.4.4 to test with ...
Comment 3 Roman Eisele 2012-05-25 01:51:40 UTC
*** Bug 49853 has been marked as a duplicate of this bug. ***
Comment 4 Roman Eisele 2012-05-25 01:54:03 UTC
*** Bug 49584 has been marked as a duplicate of this bug. ***
Comment 5 Roman Eisele 2012-05-25 01:58:28 UTC
From the reports of bug 49584 and bug 49853 it becomes clear that the same problem is present not only in Writer (see my comment #1), but also in Calc, at least in Calc 3.5.x on MacOS X. I can confirm this behaviour, too.

I set the Platform to 'MacOS X' for now, because the original report did not mention the OS used, and I have reproduced it only on MacOS (for now).


@Andras Timar:
On which platform did you see this problem first? It is a MacOS only problem or can you confirm its presence on other operating systems? And only with Writer, or also with Calc?
Thank you very much!
Comment 6 Andras Timar 2012-05-25 02:38:07 UTC
I saw first it either on Linux or Windows. CC-ed original developer, Kendy.
Comment 7 Roman Eisele 2012-05-25 08:38:46 UTC
Some additional testing done:

* REPRODUCIBLE with LOdev 3.6.0alpha0+ (Build ID: 2398b9c; date: 2012-05-24), US English langpack installed, on MacOS X 10.6.8 German. Both Writer and Calc suffer from the same issue: even if the edit field of the Find toolbar has the focus, pasted text gets inserted not into the edit field, but into the contents of the main text / spreadsheet.

* NOT REPRODUCIBLE with LibreOffice 3.5.3.2, German UI, on Windows XP; in Writer and Calc everything works as expected (i.e., the edit field of the Find toolbar retrives the text from clipboard if I press Ctrl+V). But LibreOffice 3.4.4, 3.5.3.2 and 3.5.4.1 on MacOS X 10.6.8 definitely all have the problem.


(In reply to comment #6)
> I saw first it either on Linux or Windows.

So IMHO we have two possibilites:
* The problem was never present on Windows, but only on Linux and MacOS X.
* The problem has been fixed between 2012-05-09 and now for Windows and/or Linux, maybe by the way with some other fix, but not for MacOS X ...

=> Could someone please try if this issue is still reproducible on Linux variants?

(In reply to comment #6)
> CC-ed original developer, Kendy.
A good idea, thank you!


Changed Component field to "UI", which seems most appropriate to me (feel free to change back to "Libreoffice", if this is better for some reasons).
Comment 8 Florent Angly 2012-05-25 18:43:56 UTC
Correct me if I'm wrong but it seems like Andras and Roman's queries are different.

Andras, I believe, is asking for an improvement, namely that the Find box should be automatically populated with the content of the clipboard in order to avoid having to manually paste something that has been copied. I agree that this would be a nice improvement. Coloring the all the matches in the document would also a nice extra.

Roman, on the other experiences a bug, where trying to paste content in the Find box results in content being pasted in the main document instead. The content is pasted in the main document in my case, but that's probably because the Find box never gets focus in my case. This may possibly be related: bug 47634.
Comment 9 Roman Eisele 2012-05-26 01:40:50 UTC
(In reply to comment #8)
> Correct me if I'm wrong but it seems like Andras and Roman's queries are
> different.
> 
> Andras, I believe, is asking for an improvement, namely that the Find box
> should be automatically populated with the content of the clipboard [...]
> 
> Roman, on the other experiences a bug, where trying to paste content in the
> Find box results in content being pasted in the main document instead. [...]

Thank you, Florent --
you are completely right. Oh no! How could I miss that (little but important) difference?! I'm sorry, I have totally mixed these two issues.

@Andras:
Sorry for this disorder! How should we proceed now? We need to separate these two issues again, but I can't delete the entries belonging from "my" bug (and bug 49853 and bug 49584, which are duplicates of "my" issue) from "your" bug ;-) So, I can copy my notes to bug 49853, which has a reasonable description and therefore is a good base for "my" iusse, but I can't clean "your" issue again, sorry sorry sorry. Maybe you would like to/should file a new bug for your iusse, and then we should close this messed up report and just insert a final comment hinting to the two new (separated) bug reports?! Sorry again!
Comment 10 Roman Eisele 2012-05-26 08:40:08 UTC
OK, I have moved the complete discussion about "my" issue (for the distincion, see comment #8) to bug 49853. Any discussion about "my" issue should be continued on the page for bug 49853, of course.

Therefore, PLEASE FORGET comment #1 to comment #7 -- sorry again for all the confusion I have caused just by overseeing that little difference!
Comment 11 Roman Eisele 2012-05-26 08:53:35 UTC
But giving this discussion a new start,
I can also confirm Andras' original issue and description:


(In reply to comment #0)
> It is a very frequent use case, when I have a word to search for, I copy it
> with Ctrl+C, I press Ctrl+F and ... it is not in the edit box of Find Toolbar,
> I have to press Ctrl+V. It works with the old Find and Replace (Ctrl+H) dialog.

REPRODUCIBLE on MacOS X 10.6.8 (Intel), German UI, with
* LibreOffice 3.4.4
* LibreOffice 3.5.3.2 (Build-ID: 235ab8a-3802056-4a8fed3-2d66ea8-e241b80)
* LOdev 3.6.0alpha0+ (Build ID: 2398b9c; date: 2012-05-24), US English langpack installed. (Therefore I set the Version field again to 3.4.4 release.)

I don't have a copy of 3.4.0 around, but it seems probable that the current behaviour is present since the implementation of the new Find toolbar.

The behaviour Andras describes is reproducible not only in Writer, but also in Calc. (Therefore the Component setting "UI" seems most appropriate.)


It may be disputed, however, if this is a bug (because the old "Find and Replace" dialog worked in the way expected by Andras and me), or an enhancement request, as Florent suggests in his comment #8. But this is rather a question of classification.
Comment 12 Roman Eisele 2012-08-17 15:53:41 UTC
Good news:
This issue is a duplictate of bug 37791, which has been fixed now; the fix should appear in LibO 3.6.1 (see bug 37791 for details).

*** This bug has been marked as a duplicate of bug 37791 ***