note: I've found that right (secondary) clicking on the search box, and choosing "paste" from the popup dialogue does let you paste into the box, but the standard shortcuts and menus should clearly work here.

Just for the record:
At least on MacOS X (10.6.8), already REPRODUCIBLE with LibreOffice 3.4.4, German langpack installed (probably present since 3.4.0?!). Therefore adapting the 'Version' and 'Platform' fields.

Please forget my comment #2, it was a mistake: bug 49706 is, of course, very similar, but still a mistake. Sorry! Therefore I REOPEN this bug report and add here all information which has been collected in between:


(I) This bug affects not only Calc (for Calc, see original description), but also Writer (therefore I change the Component field to "UI"). To reproduce it, use the following 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.

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


(II) This bug is REPRODUCIBLE on MacOS X (10.6.8, Intel Mac, German UI) with

1) LibreOffice 3.4.4, German langpack installed.
2) LibreOffice 3.5.3.2 (Build-ID: 235ab8a-3802056-4a8fed3-2d66ea8-e241b80), German langpack installed.
3) LibreOffice 3.5.4.1 (Build-ID: 7306755-f4f605c-738527d-1cf4bc1-9930dc8), German langpack installed.
4) LOdev 3.6.0alpha0+ (Build ID: 2398b9c; date: 2012-05-24),
US English langpack installed.

I don't have a copy of LibreOffice 3.4.0 around, but it seems probable that this bug is present in LibreOffice for MacOS X since the new Find toolbar was implemented.


(III) This bug is 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 gets the text from the clipboard if I press Ctrl+V).

Therefore, this bug seems to be MacOS X only.


(IV) TODO: Can someone please verify if the bug is present on Linux? There is at least a similar, possibly somewhat related issue on Linux (bug 47634).

*** Bug 49584 has been marked as a duplicate of this bug. ***

@Kendy:
I add your mail address to the CC list because you are the original developer of the new Find toolbar. It is a nice improvement, of course, thank you again! But on MacOS X it suffers from this bug which makes it difficult to use the Find toolbar (taking myself as an example, I often copy some text from the document and then want to paste it into the Find edit field, which does currently not work due to this bug). Therefore, it would be wonderful if you could take a look at this issue ...

@Thorsten:
I add your mail address to the CC list because you are our MacOS expert, and this bug seems to be a MacOS only issue. It would be very nice if you could take a look at it!

Thank you both in advance!

*** Bug 48920 has been marked as a duplicate of this bug. ***

*** Bug 47362 has been marked as a duplicate of this bug. ***

*** Bug 42729 has been marked as a duplicate of this bug. ***

*** Bug 39815 has been marked as a duplicate of this bug. ***

* Also REPRODUCIBLE with Impress (this is no surprise: it is just a problem with the new Find toolbar, and therefore reproducible whereever the Find toolbar is used.)

* Set Version field to 3.4.3 -- according to bug 39815 and bug 42729. Probably present since 3.4.0.

* The number of duplicates indicates the severity of this issue: it's not a terrible bug, but really annoying, and that for many people, as the number of bug reports shows.

*** Bug 46136 has been marked as a duplicate of this bug. ***

*** Bug 51201 has been marked as a duplicate of this bug. ***

*** Bug 48082 has been marked as a duplicate of this bug. ***

It's interesting: at first glance, this bugs seems to be not *that* important, and it is limited to a single platform (MacOS X); but nevertheless we have found 9 duplicates in two months, which shows that it affects really many people ...!

I almost filled out a bug report, but I decide to search first instead. Same annoying issue on OS X 10.7.4 LibreOffice 3.6.0.4 (Build ID: 932b512).

*** Bug 46046 has been marked as a duplicate of this bug. ***

*** Bug 55370 has been marked as a duplicate of this bug. ***

Still present in 3.6.4.1 rc

I too have been annoyed by this on a regular basis (and was about to raise yet another duplicate before I finally found this bug)

(In reply to comment #21)
> Still present in 3.6.4.1 rc

Thank you very much for testing! However, please do not “update” the Version field ;-): it is supposed to contain the *first* version which is known to contain the bug, *not* the last/newest one. Thank you!

Noted, thanks for educating me

*** Bug 57920 has been marked as a duplicate of this bug. ***

*** Bug 59459 has been marked as a duplicate of this bug. ***

After switching to Linux i can confirm that this bug ist NOT present in any of the recent LO-versions i have tested so far.

Confirming also on :

Master build Version 4.1.0.0.alpha0+ (Build ID: f5cde53719544c7445ab6fdb465e332ac5678b0)

OSX : 10.8.2

Oh, not good. The cursor blinks in the Search window, indicating that it has the focus, when in fact it does not.


Alex

Well the field has and has not focus because one can type normal text into it just fine. That makes this bug twice as troublesome.

*** Bug 60850 has been marked as a duplicate of this bug. ***

*** Bug 61593 has been marked as a duplicate of this bug. ***

This is seriously annoying and breaks basic UI-convention. The only way to actually search for something stored in the clipboard is to right click the searchfield and select paste.

I filled a bugreport for this behaviour some time ago. But since I do not see it here, I thought it might be important to specifiy that this behaviour (bug) also affects word 2011 for mac (if not the whole Office2011 mac suite).

Description: I type cmd+F, I type cmd+v to paste, but the pasted text appears where the cursor initially was in the text.

On: MacOSX 10.8.2 + libreoffice 4.0 (and earlier) and office 2011 for mac.

Maarten: I don't see anybody excusing a non-fix. The only factor this is not being fixed is, that neither you not me did provide a patch.

And to add something useful: This is reproducible on 10.8.3 with LO 4.0.2.2.

Request to the QA-core people: Can we raise importance from medium to high for this?

(In reply to comment #34)
> Request to the QA-core people: Can we raise importance from medium to high
> for this?

I think Major Medium is already a *very high* importance for this kind of (very) annoying bug. So, I would not like to change the priority. Also see https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg

Kind regards,
Joren

Workaround: right click the searchfield and select paste.

As annoying as this is, the workaround is trivial.  I don't know if it's my place, but I don't think this is this calls for high priority.

Has been nominated up to the mab3.6, and by proxy should also help the See Also list items.

Had recently poked at this a bit and while not certain, I made suggestion that the issue is with a set of accelerator key mappings--bug 49853, bug 55914, bug 62054 and bug 60790 are all related to a need to associate the accelerator key stroke with the desired actions "first responder" on the objects menu, or on the main menu. 

So seems like it is widget programming for Cocoa NSMenu and NSView that needs cleanup. Here is the Dev list topic: http://nabble.documentfoundation.org/Objective-C-Cocoa-NSMenu-FirstResponder-key-bindings-td4047224.html

*** Bug 63369 has been marked as a duplicate of this bug. ***

*** Bug 63934 has been marked as a duplicate of this bug. ***

*** Bug 62322 has been marked as a duplicate of this bug. ***

Actually, it is not possible to paste into *any* box in LibreOffice, including font, styles etc. 

Updated the title.

(In reply to comment #41)
> Actually, it is not possible to paste into *any* box in LibreOffice,
> including font, styles etc. 
> 
> Updated the title.

which version did you use? 4.0.4, 4.1.0 or 4.2alpha?

(In reply to comment #43)
> (In reply to comment #41)
> > Actually, it is not possible to paste into *any* box in LibreOffice,
> > including font, styles etc. 
> > 
> > Updated the title.
> 
> which version did you use? 4.0.4, 4.1.0 or 4.2alpha?

Still reproducible, not fixed. Sadly there are some serious and hard to find/fix field-focussing issues on Mac OSX. Moving this from 3.6 to 4.0

Adding myself to the CC list. This is annoying not simply because the control focus doesn't work as expected, but because the result is that the search term is pasted into the body of the document, which might go unnoticed by the user, especially if they also use LibreOffice on another platform where it does work as expected (Linux). (That happened to me the first time.)

Since someone mentioned MS Word 2011 for Mac also has this bug, I tested OpenOffice 4.0 and found it too has the same problem.

*** Bug 68465 has been marked as a duplicate of this bug. ***

Please elevate the status of this bug to critical. It can cause unnoticed destruction of data.

It may also help to change the title from "cannot paste" to "pasting overwrites other data without warning".

I add Tor Lillqvist to CC list.
I've seen him fixing a lot of MacOS specific bugs recently.

Hmm, yeah, this is an embarrassing bug. And it is LibreOffice-specific, the "search bar" thingie is something the two other products based on the same original codebase don't have.

I guess one relatively easy fix would be to not use the "search bar" on OS X but always bring up the full Find & Replace dialog window. (The one you now get with Alt+Cmd+F.) Sure, the "search bar" (is that its real name?) would be nice if it worked properly, but as it doesn't...

@V Stuart: Re: comment #37, LibreOffice (and OOo) is of course very far from a typical Cocoa application code-wise, it does not use Cocoa "widgets" for instnace, so generic instructions on how to code for Cocoa are not directly applicable to LibreOffice's code-base.

Actually, I would say that the same bug *does* exist also on Linux, but it has to be invoked in a different way: You have to use Edit:Paste while the findbar's text input field has focus, that causes a paste into the document, not into the findbar. (Control-V works as expected, pastes into the findbar.) Most likely fixing that on Linux will fix the behaviour on OS X, too.

I think that unlike on Linux, on OS X an accelerator like Command-V is more tightly coupled to actually work as if the corresponding menu entry was selected. (This is obvious from the fact that in OS X (in all applications, not just LibreOffice), when pressing for instance Command-V, one sees the "Edit" menu entry highlight for a moment.)

*** Bug 68939 has been marked as a duplicate of this bug. ***

*** Bug 71819 has been marked as a duplicate of this bug. ***

*** Bug 73758 has been marked as a duplicate of this bug. ***

CONFIRMED on Ubuntu 12.04.3 + LO 4.2.0.1

(In reply to comment #53)
> Actually, I would say that the same bug *does* exist also on Linux, but it
> has to be invoked in a different way: You have to use Edit:Paste while the
> findbar's text input field has focus, that causes a paste into the document,
> not into the findbar. (Control-V works as expected, pastes into the
> findbar.)

Yes -- this perfectly describes the behavior I see on Ubuntu.

So it looks like this really IS a bug.  Thanks for working on it.  I completely lack the skills to do it!

On Sat, 18 Jan, 2014, at 6:14 PM, bugzilla-daemon@freedesktop.org wrote:

> Qubit changed bug 49853 
> What	Removed	Added
> Whiteboard	BSA Confirmed:4.2.0.2:OSX            	BSA Confirmed:4.2.0.2:OSX Confirmed:4.2.0.1:Ubuntu            
> CC	  	qubit@runcibility.com
> 
> Comment # 61 on bug 49853 from Qubit
> CONFIRMED on Ubuntu 12.04.3 + LO 4.2.0.1
> 
> (In reply to comment #53)
> > Actually, I would say that the same bug *does* exist also on Linux, but it
> > has to be invoked in a different way: You have to use Edit:Paste while the
> > findbar's text input field has focus, that causes a paste into the document,
> > not into the findbar. (Control-V works as expected, pastes into the
> > findbar.)
> 
> Yes -- this perfectly describes the behavior I see on Ubuntu.
> 
> You are receiving this mail because:
> You are on the CC list for the bug.

Looks like this is more than just pasting text. Select All also fails to work properly: It selects the text in the document instead of text in the Find bar.

This is still happening in 4.2.0.2 on Mac OS X 10.9

Moving to mab4.1 (Bug 60270) because:
- 4.0 reached EOL (End Of Life)
- bug confirmed in later version

(In reply to comment #53)
> Actually, I would say that the same bug *does* exist also on Linux, but it
> has to be invoked in a different way: You have to use Edit:Paste while the
> findbar's text input field has focus, that causes a paste into the document,
> not into the findbar. (Control-V works as expected, pastes into the
> findbar.) Most likely fixing that on Linux will fix the behaviour on OS X,
> too.

First off, the Edit:Paste "issue" is reproducible under Windows, too.
But I wanted to notice one thing. The "Edit" menu behaviour cannot be regarded a bug. Actually, this is the way it should be: Edit menu describes actions that should be performed in edited document, not in some other auxiliary windows (such as Find toolbar edit box). The same goes for Edit->Select All, etc. (you wouldn't expect bringing another Find toolbar to search within first Find edit box when you select Edit->Find while inside find toolbar?)
Thus, this must not be "fixed", as suggested in comment 53.

The problem is that both main menu (controlling main edit area) and context menu (controlling currently active widget) have the same accelerators listed.
But in other OSes, the context menu accelerators have priority, while under OSX, main menu has.
Thus, this looks to be a clear OSX-only bug.
On other OSes, there is only visual ambiguity, when one has focus in Find (or any other auxiliary) box, clicks Edit menu and sees all those shortcuts listed there, thus has impression that they will act on document, while actually the shortcuts would work inside the auxuliary window. Well, this is just cosmetic.
Under OSX, this is really a problem, things don't work as expected. And THE way to fix this would be to DISABLE all Main Menu accelerators while caret is outside the main edit window, and restore them on entry. Of course, this could also be done on other OSes, to remove the visual ambiguity (so, when outside the main edit area, (some) main menu entries would not have accelerators listed next to them). This would fix all the mess, without need to break normal operation of Main menu.

I guess you can say it isn't a bug (and I'd argue you're dead wrong - and it's been happily labelled as a bug for nearly 2 years), but that's OK.

It does not behave the way users want or expect.  It does not behave the way other apps behave.  It is not the desired behavior.

Whether it's a bug, an anti-feature, a feature, or a brilliant new feature, it isn't what users want.

"But I wanted to notice one thing. The "Edit" menu behaviour cannot be regarded a bug. Actually, this is the way it should be: Edit menu describes actions that should be performed in edited document, not in some other auxiliary windows (such as Find toolbar edit box)."

This is plain wrong on the Mac, and not how any other app on the Mac behaves. (I do not know about Windows ir Linux). But if you are making a cross-platform app, it should work like a native app on all platforms.

On the Mac it has always been the case that you can paste into native dialog boxes, for example, either by command-key, or by menu.

"Under OSX, this is really a problem, things don't work as expected. And THE way to fix this would be to DISABLE all Main Menu accelerators while caret is outside the main edit window, and restore them on entry."

And that too would not be how native applications work on the Mac. Suggesting disabling functionality instead of fixing it is unhelpful.

(In reply to comment #69)
> And that too would not be how native applications work on the Mac.
> Suggesting disabling functionality instead of fixing it is unhelpful.

Unfortunately, I don't have a Mac. So I don't know what is "native" there. Could you explain, if native Mac applications are expected to use main menu to paste into any active vidget? I mean, do you expect that when the caret is inside "Find" vidget, you will click main menu, and then Paste, ant this will paste into Find string?

If so, isn't Mac menu Edit expected to be changed when a vidget is active, to reflect only those commands that are relevant to active vidget (i.e., to look like contect menu)?

(In reply to comment #70)
> Unfortunately, I don't have a Mac. So I don't know what is "native" there.
> Could you explain, if native Mac applications are expected to use main menu
> to paste into any active vidget?

Absoultely standard behaviour for all native applications. E.g

> I mean, do you expect that when the caret
> is inside "Find" vidget, you will click main menu, and then Paste, ant this
> will paste into Find string?

Yes.

Or you can paste a password into a password dialog. And so on.

Simply put, if you choose Paste on a Mac, when editing text, it will paste wherever the caret is. It does not matter if that is a window, a dialog box, or anything else.

Furthermore, the Mac makes no distinction whether you use the Edit menu, or a command key - the command key is regarded as just a short cut for using the menu.

> If so, isn't Mac menu Edit expected to be changed when a vidget is active,
> to reflect only those commands that are relevant to active vidget (i.e., to
> look like contect menu)?

Yes, menus are supposed to change to reflect conext. However, at the risk of getting boring, being able to paste text wherever you are typing text is expected. Any application which disabled pasting text into dialogs would be considered broken.

Then my proposition remains true: I mean, main menu must be modified on entry to vidgets, and restored on return to main edit window. The only mistake I did is what exactly should be modified: it's not shortcuts, but the menu items themselves: they must be replaced with context menu entries that work with active vidget. And this is not the same as what is seen in Linuxes and Windows.

By the way, I never meant to disable pasting; what I meant was temporarily remove DUPLICATE accelerators from main menu, that are the same in Main menu and in Context menu, so that no conflict exist, and Context menu keys would be active. Well, it's not "disabling functionality", it would enable Ctrl+V as well. But not in a native way. If main menu must be redirected under OSX, well, that should be done, but not under other OSes.

Affects me too, LibreOffice 4.2.1.1 
build ID d7dbbd7842e6a58b0f521599204e827654e1fb8b
Mac OS X 10.9 Mavericks

please MacOS X users give an update about the bug status with current 4.2.4.2 LibO release.

if bug is still here, please move it from mab4.1 list to mab4.2 since 4.1.x reached END OF LIFE

Still reproducible using latest master version -> move to mab4.2

till here in 4.2.5.2

(In reply to comment #77)
> till here in 4.2.5.2

Version field is the oldest version of LibreOffice you can reproduce the bug. Please do not change version field unless you can reproduce with an older version then 3.4.3.

Sorry for the inappropriate change. How else can you indicate the bug is still alive?
I guess there should be first seen and last seen version numbers. 

I don't understand how a bug marked as "critical" has not been given higher priority for a fix and is still there after > 3 years.

*NO IMPORTANT info for developers in this comment*

(In reply to comment #79)
> Sorry for the inappropriate change. How else can you indicate the bug is
> still alive?
> I guess there should be first seen and last seen version numbers.

Lets not discuss that here :). Please start it at our QA-mailinglist.(http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa)

> I don't understand how a bug marked as "critical" has not been given higher
> priority for a fix and is still there after > 3 years.

Sadly this is not the only bug/enhancement developers are working on. Feel free to work on it, find a developer or support this feature by funding it (see https://www.documentfoundation.org/certification/developers/).

Kind regards, Joren

I can confirm it's still here, too. Libreoffice 4.2.4.2 running on OS X 10.9.3.
Sorry, I don't have the skills to fix this, so I can't complain. But just to say, it's reported 2 years ago, marked as highest/critical. I often encounter this issue when I quickly want to look in my accounting sheets and then accidentally overwrite some values.

FYI: Collabora have a customer lined up who (I hope) may fund a fix here shortly - stay posted ...

This bug will never be corrected. There are bla-bla-bla since 2012-05-12, it's awful. I'am trying to unsubscribe from this bug CC list because of spam on my email. Hope it's possible.

This bug is still reproducible on OSX 10.9, LibreOffice 4.2.5 with Russian Language Pack.

Instruction to reproduce is the same as Roman Eisele has written:
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.

Current behaviour: The text copied in step (1) is pasted at the cursor position into the main text of the Writer document.

(In reply to comment #84)
Stop changing the status and properties of this bug report! This is creating a lot of unnecessary spam for CC'ed users/developers. Just wait and don't comment on this bug if you can't add value to this bug report. First and last warning. Thanks.

*** Bug 60309 has been marked as a duplicate of this bug. ***

I never use "Select All";  I just click on the far upper left of the spreadsheet.  But you're right -   the underlying problem is that the app doesn't behave the way it should, based on where the cursor is.

On Wed, 6 Aug, 2014, at 11:01 AM, bugzilla-daemon@freedesktop.org wrote:

> 
> Comment # 90 on bug 49853 from Sam Lehman
> I too am very annoyed by this bug. 
> 
> Not only does paste not work as expected, select all (CMD/CTRL+A) also is
> wrong.  if the cursor is inside the find toolbar box and you select all, it
> should highlight the text in the box, not selecting all of the document:
> 
> 
> http://imgur.com/sMBVB6J
> 
> You are receiving this mail because:
> You are on the CC list for the bug.

*** Bug 85615 has been marked as a duplicate of this bug. ***

bug still present in 4.3.x branch ( see Bug 85615 )

moving it to mab4.3 list since 4.2.x is EOL

TESTING on Ubuntu 14.04 + various LO versions

(In reply to angelica.cartwright from comment #0)
> Steps to reproduce:
> 1. open a spreadsheet (empty will do).
> 2. type "cmd+F" to bring up the search bar, and if necessary click on it to
> give it focus.
> 3. type "cmd+V" to try to paste into the search bar 

> Current behavior: pastes the buffer into the selected cell.
> 
> Expected behavior: should paste the buffer into the search box.

NOREPRO with LO 4.4.0.1  (as expected -- see comment #53, comment #61)

> (or use edit -> paste;
> the same effect occurs.)

CONFIRMED: when pasting using the menu; testing with 
- LO 4.4.0.1 and
- 4.5.0.0.alpha0+ 
  (Build ID: 5c60dab390d66a4d5abeaf548efecf3913b90839
   Time: 2014-12-31_00:20:30)

I tried to repro the problem with LibreOffice 3.3.0 (OOO330m19 (Build:6), tag libreoffice-3.3.0.4), but the Find interface is a separate dialog, and loses focus when I click on the 'Edit' menu, so pasting into the document seems somewhat reasonable.

UNCLEAR: LO 3.3.0.4

Changed the summary as Edit > Paste doesnt work on any operating system to paste into the find bar (tested Linux and Windows) and it shouldnt work that way. Luckily Mac users have a work around - right-click paste. :D

while right-click paste does work as expected. Both Edit:Paste and Cmd-V do not work, did you mean to change the summary to remove Edit:Paste

I hit this using version 4.4.1.2 on Mac OS X 10.10.2.

While there is a work-around (right-clicking in the "Find Text" area and using "Paste" in the resulting pull-down), I didn't learn about that until finding this bug report and reading the comments.  Also, there was no way for me to (easily) manually type the characters since I was searching for a Chinese string, which I don't know how to type.

*** Bug 91062 has been marked as a duplicate of this bug. ***

Tested with 4.4.3.2 and 4.4.2.2

*** Bug 92343 has been marked as a duplicate of this bug. ***

*** Bug 92899 has been marked as a duplicate of this bug. ***

I have this bug on Libreoffice 4.4.4.3 and Yosemite 10.10.4. 
This bug is really annoying, the user can try to c/c several times before realizing, he has paste the content of his search in a cell...

Regards,

*** Bug 95358 has been marked as a duplicate of this bug. ***

*** Bug 55914 has been marked as a duplicate of this bug. ***

Tested on AOO 3.3.0.20 (build:9567)
cmd + f opens separate find dialog, cmd + v to paste a search string works as expected. So this is not an AOO bug.

Tested on LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4

same.

→ regression

pretty sure the regression was intruduced when the search bar was introduced and since then likely this bug has always existed, so in that regard not a regression.

→ regression

It depend on point of view:

Dev view: The bug allways exist, but not visible NOT regression

User view: Previous version of Find dialog does not have this bug, new feature is buggy, so it is change to worse state and updated feature become unusable in some cases → it IS regression (weird workaround exist).

On the other hand it's time to celebrate 3rd anniversary of this bug – Happy birthday and long live.

PS: There is only one workaround – reassign shortcut to old dialog – see comment#56.

Cannot really debug that without a mac; but my theory is that

vcl/source/window/keycod.cxx

does not map the cmd+V to KeyFuncType::PASTE correctly on OS X.

Can anybody with a mac add SAL_DEBUG to vcl::KeyCode::GetFunction() and see if it returns the PASTE there?

(In reply to Jan Holesovsky from comment #108)
> Can anybody with a mac add SAL_DEBUG to vcl::KeyCode::GetFunction() and see
> if it returns the PASTE there?
I have tried debugging by setting a breakpoint at vcl::KeyCode::GetFunction() with lldb.
Then typing Cmd+V does not enter the path, i.e., it does not call the KeyCode::GetFunction() at all while usual keys such as 'a' do.

This is a infuriating bug.  Can I pay someone to fix it?!

This is an infuriating bug.  Can I pay someone to fix it?!

(In reply to Warwick from comment #111)
> This is an infuriating bug.  Can I pay someone to fix it?!

Hi Warwick,

I guess so yes.
There are developers certified that you can contact
  https://www.documentfoundation.org/get-help/professional-support/

Or alternatively start a bounty.

Thanks for your concern and will to help,
Cor

@Warwick: Fantastic idea. Throwing money at a bug is a good way to raise the incentive for devs / community to contribute a fix.

FreedomSponsers is a nice way of setting up a bug bounty for a specific bug. It seems this bug here has so far not seen any cash:

https://freedomsponsors.org/search/?s=49853

Would be nice if you could make a start. Maybe others will join. With 61 humans in cc: of this bug it should be possible to move this into an area, where fixing becomes compelling.

Bug still going strong in freshly installed 5.1.0.3 on OSX 10.11.3

(In reply to vmoutoussamy from comment #114)
> This bug is opened for about 4 years, has the Importance "Highest/critical"

Thanks for notifying this!
I'm a heavy user of the keyboard myself. (*Read all my comments in the various issues ;) )

Now Highest/Critical looks to me absolutely inappropriate for this issue.
The Highest should be set by someone working on resolving the issue.
Critical makes no sense. How often is your work cluttered by this issue? What simple work around are there?
  (I'm not on a Mac, but on Ubuntu I can open the context menu in *three*
   different ways, of which *two* with a simple key board stroke, and
   choose paste - also with a short cut - from there...)

Yes, I fully agree that it is annoying that you have to remember not to use Cmd-V. But importance Major is more appropriate. Especially since it is reported so often.
So I'm changing those settings now to be more reflecting reality.

> and has 28 duplicates bugs. Now people is starting to be so frustrated by a
> UX bug that they are ready to pay for a bounty. 

There is nothing wrong with getting involved on one or another constructive way?
(*NOTE* If there is a neat bounty, I might well be able to find someone knowing the Mac and who did a little for LibreOffice in the past..)

> Let's face the situation here guys, how can we be confident in the support
> and maintenance of LibreOffice on Mac in general, when copy/paste is not
> working for 4 years?

Again I support your frustration on this bug. Still, I thought general copy/paste is fine? And please don't forget all that is done on LibreOffice code for all kind of massive improvements that also now already have positive effect for Mac Users.
Want to see more? Yes :) Want to see them faster? If possible Yes :)
Will complaining help? I'm sorry, but I doubt. And I know developers that often put a whole lot of energy and sweat in their work, don't get a positive stimulus from it either.

Please don't take this as a personal criticism on your post. I only pick your's from the list ;)
So have a good day, and please jump in if you can think of any constructive contribution that is within your means.
Ciao - Cor

I'm sorry I have to confirm comment #115: 
 - with 5.1.0.3 on OSX 10.11.3
 - concerning both cmd-F and cmd-A
 - in writer, calc, impress and draw.

And I wish to stress the high annoyance factor, not only to Cor Nouws: The user can't always see that he has pasted something into the document. When scrolling, then deciding to cmd-F, the selection and the unintended paste can meanwhile be miles away. Then, only "doesn't paste into the search field" is his impression, but the document remains altered in error.

I once lost valuable data myself by overriding calc fields, so please do all take this bug serious, keep workflows equal on any OS and continue all the brave rocking!

Otto 
(after having made a small donation to the Doc-Foundation today)

(In reply to Cor Nouws from comment #116)
 
> Now Highest/Critical looks to me absolutely inappropriate for this issue.
> The Highest should be set by someone working on resolving the issue.
> Critical makes no sense. How often is your work cluttered by this issue?
> What simple work around are there?

The main problem is that in Calc if you press CMD+F and then CMD+V this overwrites real data in a cell that had the focus before CMD+F, which might (and usually does) go unnoticed.

Data loss sounds pretty critical to me.

@Kendy, Takeshi
comment 108 would that be influenced by /vcl/osx/vclnsapp.mm

@Tor, can something similar be done here as Matthew dug up for bug 62054

https://gerrit.libreoffice.org/#/c/11104/

http://stackoverflow.com/questions/970707/cocoa-keyboard-shortcuts-in-dialog-without-an-edit-menu

(In reply to xfrz from comment #118)
> The main problem is that in Calc if you press CMD+F and then CMD+V this
> overwrites real data in a cell that had the focus before CMD+F, which might
> (and usually does) go unnoticed.
> 
> Data loss sounds pretty critical to me.

Though - looking at my work flow and how one notices work - I do not expect that frequent, I recognize your point...

I wrote to the guy that I meant that might be interested in 'bounty-solving' this bug. I hope that will soon help.

(In reply to Cor Nouws from comment #116)
> (In reply to vmoutoussamy from comment #114)
> > Let's face the situation here guys, how can we be confident in the support
> > and maintenance of LibreOffice on Mac in general, when copy/paste is not
> > working for 4 years?
> 
> Again I support your frustration on this bug. Still, I thought general
> copy/paste is fine? And please don't forget all that is done on LibreOffice
> code for all kind of massive improvements that also now already have
> positive effect for Mac Users.
> Want to see more? Yes :) Want to see them faster? If possible Yes :)
> Will complaining help? I'm sorry, but I doubt. And I know developers that
> often put a whole lot of energy and sweat in their work, don't get a
> positive stimulus from it either.
> 
> Please don't take this as a personal criticism on your post. I only pick
> your's from the list ;)
> So have a good day, and please jump in if you can think of any constructive
> contribution that is within your means.
> Ciao - Cor

I have to apologize, maybe I didn't choose the right word. I'm not really complaining though, I'm just putting my "basic user hat" and I fully understand that this kind of feedback from a dev perceptive could be seen as something far away from a valuable feedback. Yes, this is a kind of feedback that a "project manager" would appreciate and understand for his value. So this might be the wrong place to say it, to the wrong people, but I have hoped that someone would catch this, because in the long run, users wont use any software with a flaw in a basic capabilities and won't make good publicity to his peers about this software.

(In reply to Cor Nouws from comment #120)
> (In reply to xfrz from comment #118)
> > The main problem is that in Calc if you press CMD+F and then CMD+V this
> > overwrites real data in a cell that had the focus before CMD+F, which might
> > (and usually does) go unnoticed.
> > 
> > Data loss sounds pretty critical to me.
> 
> Though - looking at my work flow and how one notices work - I do not expect
> that frequent, I recognize your point...

It has been mentioned here before, but i would like to reiterate that data might be overwritten in a cell that is off the screen already - i.e. totally impossible to *notice*.

(In reply to Cor Nouws from comment #120)

> I wrote to the guy that I meant that might be interested in 'bounty-solving'
> this bug. I hope that will soon help.

Not as much as I hoped - partly because he's working in LibreOffice code really rare, which makes the treshold a bit higher.
So it better to look for other options.

(In reply to xfrz from comment #122)

> It has been mentioned here before, but i would like to reiterate that data
> might be overwritten in a cell that is off the screen already - i.e. totally
> impossible to *notice*.

Then - after all - let me set to critical. Again..

Still present in LibreOffice 5.1.1 RC1 (LO 5.1.1.1, Mac OS X 10.11.3)

Hi Paul; thanks for testing - but rest assured that this bug will not be fixed unexpectedly without this issue being updated ;-)

Paul: I heard you were interested in looking into this, so let me add some more code pointers here...

The actual task is to find out why pressing the Cmd-V does not hit the vcl::KeyCode::GetFunction() in vcl/source/window/keycod.cxx

I'd try to put there a breakpoint, and see where is it called from when you press eg. the key 'a' (as according to comment 109, that case enters that), look up the stack, and see where it is coming from; you'll probably see something around vcl/osx/vclnsapp.mm or other .mm file.

Then I'd try to put a breakpoint there in the .mm file, and see if you get at least there when pressing Cmd-V; and then find out what is different to the 'a' case, and try to fix that - so that you get to the GetFunction().

Talking about vcl/osx/vclnsapp.mm, I am particularly suspicious of the

  if( pKeyWin && [pKeyWin isKindOfClass: [SalFrameWindow class]] )

where in the 'else', they say

  // #i94601# a window not of vcl's making has the focus.
  // Since our menus do not invoke the usual commands
  // try to play nice with native windows like the file dialog
  // and emulate them
  // precondition: this ONLY works because CMD-V (paste), CMD-C (copy) and CMD-X (cut) are
  // NOT localized, that is the same in all locales. Should this be
  // different in any locale, this hack will fail.

and continue with some stuff with cmd-c / cmd-v etc.

So maybe as the first thing, I'd try to comment out the "&& [pKeyWin isKindOfClass: [SalFrameWindow class]]" part of the if, and if that helps, we know we need to find a way that still lets the native dialogs working, but makes the cmd-v in the toolbar work.

Created attachment 122823 [details]
Backtrace from keycod.cxx after pressing a in Find box

I've been looking into this a bit as well, after being notified about it by Cor. For hardware reasons, I'm using Mac OS X 10.7 and LO 4.3, but I can reproduce the issue.

I tried some of Jan's suggestions (comment 127):

- I tried some changes on vclnsapp.mm. Commenting out the "&& [pKeyWin isKindOfClass: [SalFramWindow class]]" does not change the behavior for me, nor does commenting out the first pKeyWin section, or even the entire pKeyWin section. I reverted those changes for now.

- I did a stack backtrace on keycod.cxx, vcl::KeyCode::GetFunction(). Indeed the breakpoint does not get hit when pressing Cmd+V, but it does when pressing 'a'. The steps I took and the output are in the attached file.

Is anyone else working on this issue now? Paul? Otherwise, I'll just continue with Jan's suggestion to look up the stack, etc.

I've been able to build LO on Mac OS X 10.11 so I'll start debugging as well.

Something else I notices that may help:
The Find-box is part of a toolbar, but other toolbars such as Calcs Formula toolbar do not exhibit the wrong paste behaviour on Cmd-V or select behaviour on Cmd-A.

Paul: I can confirm what you describe.

Further findings:

Breakpoint at -[SalFrameView keyDown:] (salframeview.mm:958, frame #22 in the stack trace I posted earlier) is not triggered by Cmd+V, though it is by 'a'.

Breakpoint at -[NSWindow sendEvent:] (frame #23 in the earlier stack trace) is triggered so frequently that there is no chance to switch to the LO window and press Cmd+V.

I probably won't be working on this for the next few days. Hope you can find out more.

*** Bug 98112 has been marked as a duplicate of this bug. ***

@libreoffice@openmailbox.org 

I revert your change in the summary.
The comment #96 touches a different subject. Thanks for noticing that. But to handle that, if desired, a separate issue would be preferred.
Ciao, Cor

A little analysis of flow (debug) and code has learned:
a) The target that's hit with paste of context menu in findbar is Edit::Paste()
      Should this code also eventually be run when Cmd-V is pressed?
b) In vclnsapp.mm:
   when textfield of Findbar has focus Cmd-V, then
      in sendEvent() [pKeyWin isKindOfClass: [SalFrameWindow class]] is true
   and for that reason the else if clause with handling for Cmd-V, -C, -X and -A
      will never be hit.
c) The UI type of the findbar is vnd.sun.star.findbar:FocusToFindbar.
   Could it not being of type .uno.xxx be relevant to the bug in question?

To be continued.
p.s. I've always tried to stay away from GUI code and now remember again why.

Reminder, in the handling of Cmd-V, which (type of) window would one expect pKeyWin to point to when the text field of the findbar has focus?

Is not possible to search a text in a spreadsheet using Cmd+F , Cmd+V , enter

Shortcut Cmd+V does not work as expected when Find is open (using Cmd+F)

Current behavior: pastes the buffer into the selected cell.
Expected behavior: should paste the buffer into the Find search box.




Mac OS X  10.11.3 (El Capitan)

Libre Office: Version: 5.1.1.3
Build ID: 89f508ef3ecebd2cfb8e1def0f0ba9a803b88a6d
CPU Threads: 8; OS Version: Mac OS X 10.11.3; UI Render: default; 
Locale: de-DE (de.UTF-8)

Bug notified for version 3.4.3
I updated today to 5.1.2.1 (Mac OS 10.11.3 - El Capitan)
Bug still there.
How it is possible to update 2 major versions without fixing a "critical" problem ?

On the sidelines of this, I'm cheerful to learn my city's administration is being replaced Microsoft's Office for LibreOffice and plans to allocate 200K euros to assist in the resolution of this type of bug. Hope this will help…
https://joinup.ec.europa.eu/community/osor/news/nantes-m%C3%A9tropole-completes-switch-libreoffice

It seems this archaic bug tracking system doesn't have a way to vote, so consider this my vote. LibreOffice 5.0.5.2, OS X 10.11.4

> It seems this archaic bug tracking system doesn't have a way to vote.

Sure it does - you can send code - it is more than welcome; but let me remove a couple of developers from this bug =)

Michael: sending in code is not a thing every user is capable of. Also sending in code is something completely different than voting on a certain bug. It's sad to see key devs un-cc:-ing themselves.

Voting has been discussed a few times, I don't see any drawback to adding it. Also it doesn't hurt anybody. I understand that devs prefer to see real code patched coming in rather than many "me toos" or "+1". But since no voting exists as correctly stated by swrobel, there's no other way than posting a comment.

@Paul / Peter, where you able to dig deeper in on this bug?

@steve -_- No, sorry, this is unknown territory for me as well and I currently lack the resources to dive into this further.

@steve Neither have I given more time to this bug, but I intent to invest more time once time allows ...

Well, the root cause seems http://opengrok.libreoffice.org/xref/core/vcl/osx/vclnsapp.mm#159 :

159             // see whether the main menu consumes this event
160             // if not, we want to dispatch it ourselves. Unless we do this "trick"
161             // the main menu just beeps for an unknown or disabled key equivalent
162             // and swallows the event wholesale
163             NSMenu* pMainMenu = [NSApp mainMenu];
164             if( ! bHandled && (pMainMenu == nullptr || ! [pMainMenu performKeyEquivalent: pEvent]) )
165             {
166                 [[pKeyWin contentView] keyDown: pEvent];
167                 bHandled = GetSalData()->maKeyEventAnswer[ pEvent ];
168             }
169             else
170             {
171                 bHandled = true;  // event handled already or main menu just handled it
172             }

i.e. on OS X when pressing some shortcut, the main menu is checked first, and if it has an item with this shortcut, then a click on that menu item is simulated instead of sending the shortcut directly to the app. So because the Edit menu has "Paste" item, the OS X menu handling hijacks that shortcut, and it never passed down to the edit widget.

Now we only need to figure out what's the right way to fix this...

*** Bug 60790 has been marked as a duplicate of this bug. ***

> Now we only need to figure out what's the right way to fix this...

Seems plausible - doing the main menu paste action manually also writes to the document where the focus WAS, instead of the search widget where the focus (cursor) currently is. Which it should not do imho.

(In reply to Maxim Monastirsky from comment #142)
> Well, the root cause seems
...
> Now we only need to figure out what's the right way to fix this...

check out Matthew F's similar work for bug 62054
https://cgit.freedesktop.org/libreoffice/core/commit/?id=0350bcde37edb1f25cca68cb1447ba8f759aea15

and refs to http://stackoverflow.com/questions/970707/cocoa-keyboard-shortcuts-in-dialog-without-an-edit-menu

(In reply to V Stuart Foote from comment #145)
> (In reply to Maxim Monastirsky from comment #142)
> > Well, the root cause seems
> ...
> > Now we only need to figure out what's the right way to fix this...
> 
> check out Matthew F's similar work for bug 62054
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=0350bcde37edb1f25cca68cb1447ba8f759aea15
> 
> and refs to
> http://stackoverflow.com/questions/970707/cocoa-keyboard-shortcuts-in-dialog-
> without-an-edit-menu

sendEvent() is kind of de-multiplexer. pKeyWin is assigned the keyWindow property value (window that currently receives keyboard events).
The search bar is a SalFrameWindow; true?

If so, then the fix would be to add handling of the Cmd-A|C|V|X|z|Z events for this window - currently no special handling for these cases exists. That these events end up being handled by the document window is obviously the wrong handler is dispatched.

Where would these dispatch statements be inserted in the code ?
Already the needed dispatch statement can be found in sendEvent() and just changing but the conditions for these statements to be executed may be all that's required. Currently the condition is that the window is not a SalFrameWindow, it should probably be "if (! bHandled)" and the test for pKeyWin 

The current code does things like "if (cond) { ... return;} else if {...}". When the if true clause always causes a return, then "else" should be omitted IMHO. Applied to the code of sendEvent() the control flow will be easier to grasp.

Question: can sendEvent() recurse ? (possibly via pushback of event)
That would allow for kind of FSM style of code (though I would not dare to open a Pandorra's box).

(In reply to Paul Oranje from comment #146)
> The search bar is a SalFrameWindow; true?
No. "Frame" in LO terms is usually the whole app window.

> If so, then the fix would be to add handling of the Cmd-A|C|V|X|z|Z events
> for this window
The find widget already has that handling, it's just that the menu handling occurs before the find widget gets a chance to handle it.

> That
> these events end up being handled by the document window is obviously the
> wrong
Again - they are not handled by the document window, but by the menu handling code (going all the way through vcl's Menu and framework::MenuBarManager).

One possible solution is to make Cmd-A|C|V|X|z|Z _never_ go through the menu, but I doubt that it's the right approach in general, and esp. when considering comment 144 (i.e. that menu items should also work with the find field). For the latter, we might try to handle it in SalNSMenuItem::menuItemTriggered, or even in MenuBarManager::Select.

Maxim Monastirsky committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0975b5e4bdcd564b38b244589a44f5dd6cbdc63d

tdf#49853 Some shortcuts should always end up in the view

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Well, this is a horrible hack, but it seems to do the trick.

Note that only keyboard shortcuts are covered by this. Mouse click on Edit->Paste menu will still paste to the document. This is not trivial to fix for various reasons, so leaving this for a future investigation. Whoever interested in this part too - please open a new bug, as this one is too long already.

thanks Maxim.
sometimes brute force is required to kill some die-hard bugs.

(In reply to Maxim Monastirsky from comment #149)
Thanks !

> Note that only keyboard shortcuts are covered by this.
An reason that Shift-Z isn't covered ?

> Mouse click on Edit->Paste menu will still paste to the document.
Does a mouse click then not also cause menuItemTriggered() to be called?

(In reply to Paul Oranje from comment #151)
> > Note that only keyboard shortcuts are covered by this.
> An reason that Shift-Z isn't covered ?
The underlying widget doesn't seem to support it.

> Does a mouse click then not also cause menuItemTriggered() to be called?
Yes, but then [NSApp currentEvent] won't have the right data, so you'll need to check the menu command (i.e. mpMenuItem->mpVCLMenu->GetItemCommand(mpMenuItem->mnId) ) and construct a new NSEvent based on this. So I believe it's doable too. Maybe you interested in working on this? I'll be happy to review and push your patch when ready.

There is however one problem with customization. The menu item can be reassigned to anything else (Tools->Customize...->Keyboard) or even localized (bad idea, but still...), but the find widget has hardcoded Cmd+V etc. AFAIK. So in theory there could be some inconsistency that we'll have to handle somehow. Any idea?

Follow up covering menubar Edit > Paste behavior
https://bugs.documentfoundation.org//show_bug.cgi?id=99673

Since this is marked as verified fixed, would it be possible to please pull this up into the 5.1.x branch as well?

added "backportRequest:5.1.x" to whiteboard

let's hear from the devs if this is technically feasible.

Maxim Monastirsky committed a patch related to this issue.
It has been pushed to "libreoffice-5-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=455dbe1a568b342f07fc0f07ba849ac813010304&h=libreoffice-5-1

tdf#49853 Some shortcuts should always end up in the view

It will be available in 5.1.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Confirming the CMD+V/CMD+A issue is fixed for me in 5.1.4 RC 1.

VERIFIED FIXED on:

Version: 5.1.4.1
Build ID: a4d48e4ff0e9f93e78b6356ca7b0b6303e360356
Thread CPU: 4; OS Version: Mac OS X 10.11.4; Render: default;
Locale: it-IT (it.UTF-8)

In case anyone cares - I think this got UNFIXED in the latest update, at least in the community edition ...

According the the current status as well as the last post I see here (comment 158), this bug was verified as fixed in 2016 - though it says the fixed version was 5.1.4.1, so I'm probably reading that wrong as I don't believe version 5.x arrived until many years later. BUT:

I can, however, confirm that this BUG has returned with the recent updates to both Writer and Calc versions "7.5.0.3 (X86_64) / LibreOffice Community" (FlatPak version; I did not test the .deb release or any of the other LO components). For the record, I am experiencing this on a machine running LMDE 5, Cinnamon 5.6.7, and kernel 5.10.0-20-amd64. I won't bother with the usual description of symptoms or "how to reproduce" since the 159 existing descriptions are quite clear.

I can't of course swear to it, but I'm fairly certain I would have noticed this behavior before now if it existed. 

As for the minority view that this is NOT a bug, a paste command should paste to the location where the cursor is happily flashing and giving the user a clear "come hither" look, not somewhere on a screen full of spreadsheet cells whose currently active cell can only be determined by the notation at the opposite edge of the window.

(In reply to Frank from comment #161)
> I can, however, confirm that this BUG has returned with the recent updates
> to both Writer and Calc versions "7.5.0.3 (X86_64) / LibreOffice Community"
> (FlatPak version; I did not test the .deb release or any of the other LO
> components). For the record, I am experiencing this on a machine running
> LMDE 5, Cinnamon 5.6.7, and kernel 5.10.0-20-amd64. I won't bother with the
> usual description of symptoms or "how to reproduce" since the 159 existing
> descriptions are quite clear.

This bug was macOS specific, so you should create a new bug report if you are seeing a similar behaviour on Linux in current versions