1) OO vs LO:

Roughly this same thing occurs in OpenOffice 4.1.3.  

The difference is that the top menu item isn't `Cut`, but rather something else.

But the point is that the top menu item still gets fired sometimes from a right click and hold.

Just like in LO this is influenced by a little left or right mouse motion as part of the click and press.

With a little left mouse motion, no shortcut menu item is selected.

With a little right mouse motion, the top shortcut menu item is selected.


2) Down vs up clicking:

In both LO and OO the menu appears to get fired from the mouse up event rather than the mouse down event.  So when you right click, then hold, then move just a little to the right and release it triggers the first item in this menu.

I have played with mouse down vs mouse up event firing in another development.  (Someone suggested to me that mouse up event firing was better.)  However after trying it out I don't think mouse up triggering works very well.  Rather, I think the user expects the event firing to occur when the mouse is down clicked, not when it's up-clicked.

In this case both the down click and up click do things:  The down click opens the shortcut menu.  The up click selects an item in the shortcut menu.

However if the shortcut menu was displayed on right mouse down, AND also a mouse down fired a shortcut menu selection I don't think this shortcut menu would have this issue.

If you down click with a little left motion and get the shortcut menu, then release, then down click and hold on the shortcut menu no item is yet selected.  But when you finally release on a shortcut menu item, finally it fires.  So this proves that the shortcut menu is being triggered on an up-mouse rather than a down mouse.


3) Issue can be demonstrated now in Base, Calc, Writer, so I upgraded the bug Component from Base to LibreOffice.

Could confirm the behavior. With a little mouse-motion during clicking right mouse-button the form-control will be cut.

Have set component to LibreOffice, see comment1.

This bug appears to occur on any object that opens a shortcut menu using a right click.

Simple solution:  Open the shortcut menu a little further right and down from where the mouse right down event occurs.


The right click has three associated events that occur in this order:

  a) right button down,
  b) any mouse motion, and
  c) right button released.


These cause the following things to occur:

  * Step a: Opens any shortcut menu dialog.

  * Step b1: Possibly moves the pointer over (onto) the shortcut menu, 
  * Step b2: Or not.

  * Step c: If the mouse pointer ends up on top of the shortcut menu, select a shortcut menu item.


Steps b1 and c create the bug.  

We have to accept the possibility that motion onto the shortcut menu in step b can occur.  

Unless a drag is involved, I think the user expects a click to do just one thing at a time.  But in this case it is sometimes (with a tiny amount of mouse motion) doing two things: opening and selecting.


Three possible solutions:

A) Fire shortcut selection with right (or left) down events (rather than up events).

B) After opening a shortcut menu, make sure a right release does not unintentionally select an item.

C) Open the shortcut a little more to the right and down from where the right mouse is pressed down (just a few pixels will probably do).  

 

Discussion of alternatives:

Solution A is radical, and takes away the possibility of right press, move to menu, and right release behavior.   

Solution C is really just one way of implementing solution B.  I think it is probably the safest and easiest way to fix this issue.  

Furthermore I noticed that in both FireFox and Chrome this is how they work.  They have the exact same issue, like right here when I am editing this text, and I press and hold the right mouse button down.  I then get a shortcut menu.  And if I continue to hold the right button down, and move the mouse right, and then down a bit, the pointer moves into this shortcut menu and lights up the first menu selection.  If I then release the right button the event is fired and the menu selection is performed.

Therefore I favor solution C.

(In reply to Howard Johnson from comment #4)
> Unless a drag is involved, I think the user expects a click to do just one
> thing at a time.
Well, different users have different expectations. Please take a look at these two opposite questions:

https://superuser.com/questions/1166014/how-to-show-context-menu-on-mouse-up-instead-of-mouse-down

https://superuser.com/questions/1083706/show-context-menu-on-mouse-down-event

> Three possible solutions:
> 
> A) Fire shortcut selection with right (or left) down events (rather than up
> events).
> 
> B) After opening a shortcut menu, make sure a right release does not
> unintentionally select an item.
> 
> C) Open the shortcut a little more to the right and down from where the
> right mouse is pressed down (just a few pixels will probably do).  
I don't think any of these is a good idea, as any OS/GUI toolkits that I'm aware of, work the same as LO currently (i.e. the context menu opens at the cursor position, and the mouse up event used for executing menu items). There's no reason for LO to be different.

What might make more sense, is to make the context menu show on mouse up event, i.e it will require a full right click, rather than just mouse down. But, as said above, not everyone will be happy with this. As a solution, we might consider adding a configuration setting which will allow controlling this behavior (although I'm not excited about such possibility).

In fact, there seem to be different conventions depending on OS/DE. Under Linux both Gtk and Qt apps seem to use mouse down for showing context menus, same with macOS. But under Windows usually mouse up is used, at least in standard Windows apps (explorer, notepad etc.). And indeed, it appears that cross-platform apps actually respect this difference. From my tests, Firefox, Chrome and Qt Creator use mouse down under Linux, but mouse up under Windows. So it might make sense for LO to follow that path as well, so keep the current behavior under Linux and macOS (at least as default), but change to mouse up under Windows.

Created attachment 138794 [details]
Windows 10, LO 5 snap

Note the thin white border above and to the sides of the Cut selection box.  Important: The blue box does not activate until you move the mouse down and to the right a few pixels, effectively moving across the white border and into the area where the blue then appears.  Contrast this to linux, LO 6, which does not have this thin white border.

Created attachment 138795 [details]
buggy linux 9.3/cinnamon 3.2.7 shortcut menu w/o white border

Dear Howard Johnson,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug