Is this bug going to be fixed in the near future? It is really annoying and happens nearly every time. 
It only appears for files which are on the Desktop (folder view)

Folder bugs can't be fixed if they're reported against the wrong component and the reports aren't seen.

Do you use single click or double click?

I use single click. For the future...where should i have reported this bug?

Against the "Folder" component of product "plasmashell".

Do you need any further information because the status of this bug is "NEEDSINFO WAITINGFORINFO"?

Not at the moment, thanks.

I can't reproduce this. The code changed a bit since 5.5.5; please reopen if the problem persists with 5.6.x.

At the moment I have Plasma 5.6.1 installed and it still happens...

Could you record and attach a short video using e.g. vokoscreen? It might give me a better clue about what's going on.

Created attachment 98274 [details]
behaviour of right clicking

you can see the behaviour on second 5 of the video...

I only did a single right click on the file

Thank you, that's helpful. I'll try to get around to this problem soon.

This bug just started happening to me after I upgraded Kubuntu to version 16.04 (from 15.10).

This still happens in 5.7.2.

Note that the file is only opened if you right-click and immediately release the mouse button.
If you keep it pressed, the file is never opened, only the context menu appears.
So that's at least a workaround.

Maybe related: if you drag and drop an entry from the application menu to the folderview it is also "opened". You can see the popup that asks whether you want to copy/move/symlink for a second but it disappears again before you can actually choose anything and the application is started instead.
Only seems to happen with Kicker though, not Kickoff.

The latter is actually a bug in Kicker it seems.

Git commit 0065d3548c7db695b06d80250b11d018214967dc by Eike Hein.
Committed on 23/07/2016 at 00:46.
Pushed by hein into branch 'Plasma/5.7'.

Don't activate it on release events when a drag was started prior to it.

M  +1    -0    applets/kicker/package/contents/ui/ItemListDelegate.qml
M  +1    -0    applets/kicker/package/contents/ui/SideBarItem.qml

http://commits.kde.org/plasma-desktop/0065d3548c7db695b06d80250b11d018214967dc

Possibly related:  Today on Manjaro w/ plasma 5.6.5 I had desktop icons in folder view layout launching with just a single right-click.  No menu displayed - just instantly launched the application.  I realize this is somewhat different from the bug reported above, but it's similar and I couldn't reproduce it after logging out and back in, so I won't file a separate report.

(In reply to Eike Hein from comment #16)
> The latter is actually a bug in Kicker it seems.

Ok, sorry.
I can confirm that your commit fixes that problem.
Thanks.

No need to be sorry, thanks for the report!

I still want to address these right-click woes, but it's being hampered by the fact that I personally can't reproduce it and the code does the right thing already (the click handler checks for the right mouse button and balks out). This might need more complicated state to reproduce (a la bug 366065) or be a Qt bug (lying about which button was used in the event handler).

(In reply to kdebugs from comment #18)
> Possibly related:  Today on Manjaro w/ plasma 5.6.5 I had desktop icons in
> folder view layout launching with just a single right-click.  No menu
> displayed - just instantly launched the application.  I realize this is
> somewhat different from the bug reported above, but it's similar and I
> couldn't reproduce it after logging out and back in, so I won't file a
> separate report.

It may have been the same problem, though in my experience the context menu does show up, only the file is opened at the same time.

Maybe your right-handed/left-handed mouse settings got temporarily messed up for some reason? ;-)

(In reply to Eike Hein from comment #20)
> No need to be sorry, thanks for the report!

Ok, but normally I would have opened a separate bug report. ;-)
It just seemed to have the same cause...

> I still want to address these right-click woes, but it's being hampered by
> the fact that I personally can't reproduce it and the code does the right
> thing already (the click handler checks for the right mouse button and balks
> out). This might need more complicated state to reproduce (a la bug 366065)
> or be a Qt bug (lying about which button was used in the event handler).

It's quite reliably reproducible here (since 5.5 or so).
I plan to investigate further myself, just didn't have time yet.

For the record, this happened with Qt 5.6 and still happens with 5.7.
I'm not sure if it was a problem with 5.5 too, but I will check.

(In reply to Wolfgang Bauer from comment #21)
> It may have been the same problem, though in my experience the context menu
> does show up, only the file is opened at the same time.

In the upload provided in comment #11, you can see that the context menu opens but immediately disappears.  The appearance or lack of the menu may just come down to the speed and current load of the particular machine.  I can quite reliably reproduce this bug by continually left-clicking the desktop followed by right-clicking the icon repeatedly until it launches.  When it does launch, a context menu does NOT appear for me, however when I tried to capture that with my screen recorder, it slowed things down enough that the context menu did momentarily appear, as in the attachment already uploaded.

I did have it happen on the first right-click once today - what was most different yesterday was that it was happening first time, every time, until I logged out.

> Maybe your right-handed/left-handed mouse settings got temporarily messed up
> for some reason? ;-)

Nothing else was backward, and I would have noticed if I got a context menu with a left-click.

(In reply to kdebugs from comment #23)
> (In reply to Wolfgang Bauer from comment #21)
> > Maybe your right-handed/left-handed mouse settings got temporarily messed up
> > for some reason? ;-)
> 
> Nothing else was backward, and I would have noticed if I got a context menu
> with a left-click.

All right, that was just a though.
And just to be clear, I didn't want to deny the existance of this bug, rather the opposite. As I wrote, I can reproduce it quite reliable here, on two different systems and in a VM. But in my case, the context menu does reliably appear and stays.

(In reply to Wolfgang Bauer from comment #22)
> For the record, this happened with Qt 5.6 and still happens with 5.7.
> I'm not sure if it was a problem with 5.5 too, but I will check.

I can reproduce it in a VM with openSUSE Leap 42.1 too, which uses Plasma 5.5.5 and Qt 5.5.1.
So it apparently is not caused by a change or bug in Qt 5.6 at least...

This is actually caused by a Qt bug; my fix for it is stuck since a while ago - https://codereview.qt-project.org/#/c/146786/

(In reply to Eike Hein from comment #25)
> This is actually caused by a Qt bug; my fix for it is stuck since a while
> ago - https://codereview.qt-project.org/#/c/146786/

In reading that bug, the "common example" given at the top describes "clicking outside the popup, and then clicking in the same spot that was clicked to dismiss the popup."  That sounds a whole lot more like Bug 366065 than this bug.  To be clear, this bug describes files being opened exactly on the right-click of that file icon, and NOT on clicking elsewhere to dismiss the popup menu.

Likewise, the other example given is always reproducible: "on the desktop surface: Right-click empty space to get context menu, right-click above [i.e. on] desktop icon to dismiss menu, right-click icon again and you still get the empty-space context instead of the icon one."
That explains how you might get the wrong context menu in right-clicking a desktop icon, but how does it explain opening that file/link when you right-click it?

Also, that Qt bug and Bug 366065 are always reproducible, whereas this bug is only "Reproducible: Sometimes", which makes this bug seem more like a timing problem, race condition, or something dependent on less obvious circumstances.

My assumption is that this bug only happens after the state previously got corrupted by using the context menu elsewhere. This is not included in any of the steps-to-reproduce, but I can't reproduce the problem otherwise, and reading the code I can't see how it would happen otherwise - unless there's a different Qt bug that causes mouse.buttons in MouseArea's clicked() handler to be wrong, which is also possible.

Here's an updated patch for Qt 5.7 if you want to test: https://codereview.qt-project.org/#/c/166455/

(In reply to Eike Hein from comment #27)
> My assumption is that this bug only happens after the state previously got
> corrupted by using the context menu elsewhere.

Well, in my case this occurs right after login, without doing anything else first.
I.e. I just right-click on an icon in the folderview after logging in and it gets opened (in addition to showing the context menu).

(In reply to Eike Hein from comment #28)
> Here's an updated patch for Qt 5.7 if you want to test:
> https://codereview.qt-project.org/#/c/166455/

I tried it and it does NOT help with this problem.

Btw, Qt 5.7.0 failed to compile with this patch here, I had to remove the "0L" parameter in the call to deliverHoverEvent().

I noticed meanwhile that this only happens if I tap the right mouse button extremely shortly.
If I keep it pressed for a "longer" period (maybe 0.1 seconds, hard to say exactly...), the file/icon is *not* opened.

Maybe this helps in reproducing the issue...

For me, both on a desktop computer with nvidia and on a laptop with Intel, the only way of right clicking an item on the desktop without opening it is holding the right mouse button for 1-2 seconds (Manjaro Testing with plasma-workspace-5.7.4).

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

Hey,

I filed a report on the same topic (Bug 368793) and found this bug report later. Therefore I marked my bug report as duplicate of this one.
The problem exists for me in Plasma 5.5.5 (openSUSE Leap 42.1) as well as in Plasma 5.8 (KDE Neon GIT-stable branch) and can be always be reproduced. It happens when the right mouse button is clicked very fast, the icon is not selected previously (although I'm not sure if this makes a difference). The problem does not exist with slow right mouse button clicks.

I used xev to make sure that no mouse movement is involved or others buttons are pressed simultaneously. It is reproducible with different usb mice. The bug was also tested on a notebook using the touchpad keys to be certain there is no pointer movement.

The bug is present in plasm a 5.8.1 (Neon Dev stable). I have a folder view widget in my panel. If i invoke it and right click an item, the item opens and the right click menu appears at the same time.

Problem still present on Plasma 5.8.2 (Qt 5.7).

Right-clicking on files that are on the desktop (folder view) often (not always) opens them, in addition of opening the context menu.

It's a really annoying bug...

Created attachment 103044 [details]
Possible patch

Can you please test the following patch?

I can sometimes trigger the bug and turns out that mouse.buttons is 0 for clicked events whereas mouse.button is properly set. It should bail out when released with right mouse button as that opens the context menu but the condition is never met.

According to documentation this looks intentional, at least it says "For mouse move events […]. For mouse press and double click events […]. For mouse release events […]." I can see no mention of regular "clicked", no idea why that is, though.

(In reply to Kai Uwe Broulik from comment #36)
> Created attachment 103044 [details]
> Possible patch
> 
> Can you please test the following patch?

I tried it, and the patch does indeed fix the problem here.

Patch seems fine, please commit Kai.

Git commit d2fde361d3c8fb40fb6c1e53e4178042799b6691 by Kai Uwe Broulik.
Committed on 09/01/2017 at 07:28.
Pushed by broulik into branch 'Plasma/5.8'.

[Folder View] Fix right click erroneously opening files

It turns out mouse.buttons is 0 for "clicked" events whereas mouse.button is properly set.
It should bail out when released with right mouse button as that opens the context menu
but this condition is never met.

According to documentation this looks intentional, at least it says "For mouse move
events […]. For mouse press and double click events […]. For mouse release events […]."
I can see no mention of regular "clicked", no idea why that is, though.
FIXED-IN: 5.8.6

M  +1    -1    containments/desktop/package/contents/ui/FolderView.qml

https://commits.kde.org/plasma-desktop/d2fde361d3c8fb40fb6c1e53e4178042799b6691

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