Bug Hunting Session
Bug 49853 - Cmd-V or Cmd-A inside toolbar-hosted edit fields paste into document instead (OS X only)
Summary: Cmd-V or Cmd-A inside toolbar-hosted edit fields paste into document instead ...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
3.4.3 release
Hardware: Other Mac OS X (All)
: highest critical
Assignee: Maxim Monastirsky
URL:
Whiteboard: BSA Confirmed:4.2.0.2:OSX target:5.2....
Keywords: dataLoss
: 39815 42729 46046 46136 47362 48082 48920 49584 51201 55370 55914 57920 59459 60309 60790 60850 61593 62322 63369 63934 68465 68939 71819 73758 85615 91062 92343 92899 95358 98112 (view as bug list)
Depends on:
Blocks: MacOS-Wishlist Shortcuts-Accelerators
  Show dependency treegraph
 
Reported: 2012-05-12 14:53 UTC by angelica.cartwright
Modified: 2018-02-07 16:48 UTC (History)
64 users (show)

See Also:
Crash report or crash signature:


Attachments
Backtrace from keycod.cxx after pressing a in Find box (6.13 KB, text/plain)
2016-02-20 18:33 UTC, Peter Nowee
Details

Note You need to log in before you can comment on or make changes to this bug.
Description angelica.cartwright 2012-05-12 14:53:54 UTC
Problem description: When I try to paste into the search bar, my text is pasted into the currently selected cell, even though the search bar has focus. Typing normally does enter text into the find box.

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 (or use edit -> paste; the same effect occurs.)

Current behavior: pastes the buffer into the selected cell.

Expected behavior: should paste the buffer into the search box.

Platform (if different from the browser): (Mac OS 10.6 Snow Leopard)
              
Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.168 Safari/535.19
Comment 1 angelica.cartwright 2012-05-12 15:13:01 UTC
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.
Comment 2 Roman Eisele 2012-05-25 01:51:40 UTC

*** This bug has been marked as a duplicate of bug 49706 ***
Comment 3 Roman Eisele 2012-05-25 07:25:24 UTC
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.
Comment 4 Roman Eisele 2012-05-26 08:32:22 UTC
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).
Comment 5 Roman Eisele 2012-05-26 08:35:02 UTC
*** Bug 49584 has been marked as a duplicate of this bug. ***
Comment 6 Roman Eisele 2012-05-26 09:03:27 UTC
@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!
Comment 7 Roman Eisele 2012-05-27 00:28:21 UTC
*** Bug 48920 has been marked as a duplicate of this bug. ***
Comment 8 Roman Eisele 2012-05-27 00:30:08 UTC
*** Bug 47362 has been marked as a duplicate of this bug. ***
Comment 9 Roman Eisele 2012-05-27 00:32:50 UTC
*** Bug 42729 has been marked as a duplicate of this bug. ***
Comment 10 Roman Eisele 2012-05-27 00:34:35 UTC
*** Bug 39815 has been marked as a duplicate of this bug. ***
Comment 11 Roman Eisele 2012-05-27 00:41:20 UTC
* 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.
Comment 12 Roman Eisele 2012-05-27 00:58:56 UTC
*** Bug 46136 has been marked as a duplicate of this bug. ***
Comment 13 mark 2012-06-18 15:39:32 UTC
*** Bug 51201 has been marked as a duplicate of this bug. ***
Comment 14 Roman Eisele 2012-07-10 16:55:25 UTC
*** Bug 48082 has been marked as a duplicate of this bug. ***
Comment 15 Roman Eisele 2012-07-10 17:07:11 UTC
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 ...!
Comment 16 Jason Ogden 2012-08-17 20:56:37 UTC
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).
Comment 17 Roman Eisele 2012-08-24 15:35:25 UTC
*** Bug 46046 has been marked as a duplicate of this bug. ***
Comment 18 ksb 2012-09-11 20:48:09 UTC Comment hidden (me-too)
Comment 19 Roman Eisele 2012-09-27 07:26:53 UTC
*** Bug 55370 has been marked as a duplicate of this bug. ***
Comment 20 Frantisek Erben 2012-10-16 14:24:00 UTC Comment hidden (me-too)
Comment 21 Matthew Francis 2012-11-23 06:49:11 UTC
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)
Comment 22 Roman Eisele 2012-11-23 07:48:34 UTC
(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!
Comment 23 Matthew Francis 2012-11-23 08:08:22 UTC
Noted, thanks for educating me
Comment 24 Emir Sarı (away) 2012-12-06 00:26:20 UTC
*** Bug 57920 has been marked as a duplicate of this bug. ***
Comment 25 Emir Sarı (away) 2013-01-17 17:06:15 UTC
*** Bug 59459 has been marked as a duplicate of this bug. ***
Comment 26 ojaehn 2013-01-18 12:11:01 UTC
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.
Comment 27 Alex Thurgood 2013-01-18 15:37:55 UTC
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
Comment 28 Jessi Björk 2013-01-18 16:41:39 UTC
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.
Comment 29 Emir Sarı (away) 2013-02-27 19:35:24 UTC
*** Bug 60850 has been marked as a duplicate of this bug. ***
Comment 30 Jorendc 2013-03-01 20:03:46 UTC
*** Bug 61593 has been marked as a duplicate of this bug. ***
Comment 31 Maarten Brouwers 2013-03-11 15:29:15 UTC
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.
Comment 32 yvanduvent 2013-03-11 15:43:55 UTC
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.
Comment 33 Maarten Brouwers 2013-03-11 15:52:02 UTC Comment hidden (off-topic)
Comment 34 retired 2013-04-04 20:50:17 UTC
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?
Comment 35 Jorendc 2013-04-04 20:54:14 UTC
(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
Comment 36 Kurt Werle 2013-04-04 21:10:41 UTC
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.
Comment 37 V Stuart Foote 2013-04-04 22:24:06 UTC
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
Comment 38 andrew.43 2013-04-10 12:35:51 UTC
*** Bug 63369 has been marked as a duplicate of this bug. ***
Comment 39 Jorendc 2013-04-26 20:29:29 UTC
*** Bug 63934 has been marked as a duplicate of this bug. ***
Comment 40 Jorendc 2013-05-19 21:23:57 UTC
*** Bug 62322 has been marked as a duplicate of this bug. ***
Comment 41 Emir Sarı (away) 2013-06-16 14:57:26 UTC
Actually, it is not possible to paste into *any* box in LibreOffice, including font, styles etc. 

Updated the title.
Comment 42 Tom 2013-06-16 15:05:10 UTC Comment hidden (off-topic)
Comment 43 tommy27 2013-08-03 09:52:58 UTC
(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?
Comment 44 Jorendc 2013-08-03 09:54:53 UTC
(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
Comment 45 David H. Gutteridge 2013-08-07 00:44:16 UTC
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.
Comment 46 ign_christian 2013-08-24 10:11:08 UTC
*** Bug 68465 has been marked as a duplicate of this bug. ***
Comment 47 Ralph Martin 2013-08-24 15:55:54 UTC
Please elevate the status of this bug to critical. It can cause unnoticed destruction of data.
Comment 48 Ralph Martin 2013-08-24 15:57:00 UTC
It may also help to change the title from "cannot paste" to "pasting overwrites other data without warning".
Comment 49 tommy27 2013-08-24 16:31:18 UTC
I add Tor Lillqvist to CC list.
I've seen him fixing a lot of MacOS specific bugs recently.
Comment 50 Tor Lillqvist 2013-08-25 21:17:53 UTC
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.
Comment 51 Tor Lillqvist 2013-08-25 21:30:39 UTC
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...
Comment 52 Tor Lillqvist 2013-08-25 21:42:30 UTC
@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.
Comment 53 Tor Lillqvist 2013-08-26 07:14:07 UTC
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.)
Comment 54 tommy27 2013-09-05 21:23:15 UTC
*** Bug 68939 has been marked as a duplicate of this bug. ***
Comment 55 Alexander Petrossian (PAF) 2013-10-31 07:31:50 UTC Comment hidden (me-too)
Comment 56 Frantisek Erben 2013-10-31 08:39:57 UTC Comment hidden (no-value)
Comment 57 Jorendc 2013-11-20 06:26:11 UTC
*** Bug 71819 has been marked as a duplicate of this bug. ***
Comment 58 Tom 2013-11-20 06:35:06 UTC Comment hidden (off-topic)
Comment 59 Jorendc 2014-01-18 08:36:14 UTC
*** Bug 73758 has been marked as a duplicate of this bug. ***
Comment 60 retired 2014-01-18 13:49:48 UTC Comment hidden (me-too)
Comment 61 Robinson Tryon (qubit) 2014-01-18 23:14:38 UTC
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.
Comment 62 Ivan Stephen 2014-01-18 23:34:27 UTC
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.
Comment 63 Ambrose Li 2014-01-19 00:07:47 UTC
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.
Comment 64 deepjungle.maca 2014-01-24 13:41:56 UTC
This is still happening in 4.2.0.2 on Mac OS X 10.9
Comment 65 stragu 2014-02-12 08:13:44 UTC
Moving to mab4.1 (Bug 60270) because:
- 4.0 reached EOL (End Of Life)
- bug confirmed in later version
Comment 66 Mike Kaganski 2014-02-23 01:39:43 UTC
(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.
Comment 67 Kurt Werle 2014-02-23 03:44:57 UTC
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.
Comment 68 Ralph Martin 2014-02-23 08:54:05 UTC
"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.
Comment 69 Ralph Martin 2014-02-23 08:56:22 UTC
"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.
Comment 70 Mike Kaganski 2014-02-23 09:14:38 UTC
(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)?
Comment 71 Ralph Martin 2014-02-23 09:46:31 UTC
(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.
Comment 72 Mike Kaganski 2014-02-23 09:52:28 UTC
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.
Comment 73 Mike Kaganski 2014-02-23 10:13:37 UTC
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.
Comment 74 nrarbeedsob 2014-03-25 06:46:45 UTC
Affects me too, LibreOffice 4.2.1.1 
build ID d7dbbd7842e6a58b0f521599204e827654e1fb8b
Mac OS X 10.9 Mavericks
Comment 75 tommy27 2014-05-10 11:38:58 UTC
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
Comment 76 Jorendc 2014-05-10 11:50:02 UTC
Still reproducible using latest master version -> move to mab4.2
Comment 77 Ralph Martin 2014-06-20 15:02:25 UTC
till here in 4.2.5.2
Comment 78 Jorendc 2014-06-20 15:05:10 UTC
(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.
Comment 79 Ralph Martin 2014-06-20 15:13:08 UTC
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.
Comment 80 Jorendc 2014-06-20 15:22:11 UTC
*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
Comment 81 Mark 2014-06-20 15:23:50 UTC
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.
Comment 82 Michael Meeks 2014-06-20 15:57:13 UTC
FYI: Collabora have a customer lined up who (I hope) may fund a fix here shortly - stay posted ...
Comment 83 irregularr 2014-06-22 09:40:23 UTC
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.
Comment 84 irregularr 2014-06-22 11:49:23 UTC
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.
Comment 85 Jorendc 2014-06-22 13:57:45 UTC
(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.
Comment 86 Jorendc 2014-06-24 15:32:29 UTC
*** Bug 60309 has been marked as a duplicate of this bug. ***
Comment 87 Robert von Burg 2014-07-23 14:43:14 UTC Comment hidden (me-too)
Comment 88 Tom 2014-07-23 14:50:07 UTC Comment hidden (off-topic)
Comment 89 Ivan Stephen 2014-07-23 16:50:56 UTC Comment hidden (me-too)
Comment 90 Sam Lehman 2014-08-06 15:01:37 UTC Comment hidden (me-too)
Comment 91 Ivan Stephen 2014-08-06 15:44:15 UTC
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.
Comment 92 thulani makhathini 2014-09-23 11:33:59 UTC Comment hidden (no-value)
Comment 93 tommy27 2014-10-30 03:36:40 UTC
*** Bug 85615 has been marked as a duplicate of this bug. ***
Comment 94 tommy27 2014-11-29 17:37:00 UTC
bug still present in 4.3.x branch ( see Bug 85615 )

moving it to mab4.3 list since 4.2.x is EOL
Comment 95 Robinson Tryon (qubit) 2015-01-06 20:51:50 UTC
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
Comment 96 Yousuf Philips (jay) (retired) 2015-02-04 21:27:42 UTC
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
Comment 97 Vossman 2015-02-05 21:36:47 UTC
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
Comment 98 Chris Jerdonek 2015-03-21 16:47:24 UTC
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.
Comment 99 Alex Thurgood 2015-05-04 10:56:25 UTC
*** Bug 91062 has been marked as a duplicate of this bug. ***
Comment 100 marcosgdf 2015-05-12 14:56:35 UTC
Tested with 4.4.3.2 and 4.4.2.2
Comment 101 Alex Thurgood 2015-06-26 08:51:08 UTC
*** Bug 92343 has been marked as a duplicate of this bug. ***
Comment 102 Alex Thurgood 2015-07-24 07:58:40 UTC
*** Bug 92899 has been marked as a duplicate of this bug. ***
Comment 103 vmoutoussamy 2015-07-27 13:22:27 UTC
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,
Comment 104 Alex Thurgood 2015-11-02 10:13:45 UTC
*** Bug 95358 has been marked as a duplicate of this bug. ***
Comment 105 Alex Thurgood 2015-11-02 10:15:15 UTC
*** Bug 55914 has been marked as a duplicate of this bug. ***
Comment 106 steve -_- 2015-11-05 16:12:04 UTC
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.
Comment 107 Frantisek Erben 2015-11-05 22:35:28 UTC
→ 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.
Comment 108 Jan Holesovsky 2015-11-06 07:48:51 UTC
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?
Comment 109 Takeshi Abe 2015-11-11 08:51:41 UTC
(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.
Comment 110 Warwick 2016-02-10 10:36:11 UTC
This is a infuriating bug.  Can I pay someone to fix it?!
Comment 111 Warwick 2016-02-10 10:36:31 UTC
This is an infuriating bug.  Can I pay someone to fix it?!
Comment 112 Cor Nouws 2016-02-10 11:27:22 UTC
(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
Comment 113 steve -_- 2016-02-11 00:13:08 UTC
@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.
Comment 114 vmoutoussamy 2016-02-11 09:48:56 UTC Comment hidden (no-value)
Comment 115 xfrz 2016-02-11 10:06:15 UTC
Bug still going strong in freshly installed 5.1.0.3 on OSX 10.11.3
Comment 116 Cor Nouws 2016-02-11 10:23:53 UTC
(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
Comment 117 Otto_80 2016-02-11 11:52:35 UTC
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)
Comment 118 xfrz 2016-02-11 12:15:23 UTC
(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.
Comment 119 V Stuart Foote 2016-02-11 14:38:36 UTC
@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
Comment 120 Cor Nouws 2016-02-11 14:58:45 UTC
(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.
Comment 121 vmoutoussamy 2016-02-11 16:54:08 UTC
(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.
Comment 122 xfrz 2016-02-12 12:57:36 UTC
(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*.
Comment 123 Cor Nouws 2016-02-13 15:59:08 UTC
(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.
Comment 124 Cor Nouws 2016-02-16 07:36:59 UTC
(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..
Comment 125 Paul Oranje 2016-02-18 10:28:34 UTC
Still present in LibreOffice 5.1.1 RC1 (LO 5.1.1.1, Mac OS X 10.11.3)
Comment 126 Michael Meeks 2016-02-18 11:55:31 UTC
Hi Paul; thanks for testing - but rest assured that this bug will not be fixed unexpectedly without this issue being updated ;-)
Comment 127 Jan Holesovsky 2016-02-19 07:59:21 UTC
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.
Comment 128 Peter Nowee 2016-02-20 18:33:18 UTC
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.
Comment 129 Paul Oranje 2016-02-20 19:38:10 UTC
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.
Comment 130 Peter Nowee 2016-02-20 22:06:39 UTC
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.
Comment 131 V Stuart Foote 2016-02-24 05:01:03 UTC
*** Bug 98112 has been marked as a duplicate of this bug. ***
Comment 132 Cor Nouws 2016-02-24 11:45:14 UTC
@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
Comment 133 Paul Oranje 2016-02-29 14:47:04 UTC
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.
Comment 134 Paul Oranje 2016-02-29 14:54:00 UTC
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?
Comment 135 Bob K 2016-03-28 22:46:18 UTC
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)
Comment 136 Mr Diab 2016-03-29 11:37:52 UTC
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
Comment 137 swrobel 2016-04-26 23:50:47 UTC
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
Comment 138 Michael Meeks 2016-04-27 10:45:18 UTC
> 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 =)
Comment 139 steve -_- 2016-04-27 11:31:01 UTC
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?
Comment 140 Peter Nowee 2016-04-27 12:42:23 UTC
@steve -_- No, sorry, this is unknown territory for me as well and I currently lack the resources to dive into this further.
Comment 141 Paul Oranje 2016-04-27 15:05:37 UTC
@steve Neither have I given more time to this bug, but I intent to invest more time once time allows ...
Comment 142 Maxim Monastirsky 2016-04-28 11:18:48 UTC
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...
Comment 143 Maxim Monastirsky 2016-04-28 11:38:51 UTC
*** Bug 60790 has been marked as a duplicate of this bug. ***
Comment 144 xfrz 2016-04-28 11:39:57 UTC
> 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.
Comment 145 V Stuart Foote 2016-04-28 16:05:19 UTC
(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
Comment 146 Paul Oranje 2016-04-28 21:30:55 UTC
(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).
Comment 147 Maxim Monastirsky 2016-04-30 19:18:12 UTC
(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.
Comment 148 Commit Notification 2016-05-01 13:22:04 UTC
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.
Comment 149 Maxim Monastirsky 2016-05-01 13:33:48 UTC
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.
Comment 150 tommy27 2016-05-01 14:14:30 UTC
thanks Maxim.
sometimes brute force is required to kill some die-hard bugs.
Comment 151 Paul Oranje 2016-05-01 15:03:04 UTC
(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?
Comment 152 Maxim Monastirsky 2016-05-01 15:57:45 UTC
(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?
Comment 153 steve -_- 2016-05-04 12:54:42 UTC
Follow up covering menubar Edit > Paste behavior
https://bugs.documentfoundation.org//show_bug.cgi?id=99673
Comment 154 David H. Gutteridge 2016-05-11 06:28:30 UTC
Since this is marked as verified fixed, would it be possible to please pull this up into the 5.1.x branch as well?
Comment 155 tommy27 2016-05-11 07:28:29 UTC
added "backportRequest:5.1.x" to whiteboard

let's hear from the devs if this is technically feasible.
Comment 156 Commit Notification 2016-05-19 14:48:52 UTC
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.
Comment 157 David H. Gutteridge 2016-06-02 21:48:40 UTC
Confirming the CMD+V/CMD+A issue is fixed for me in 5.1.4 RC 1.
Comment 158 Marina Latini (CIB) 2016-06-03 08:30:01 UTC
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)