Bug 414762

Summary: mousearea onClicked dialog popup opens in wrong place unless window is minimized and reopened
Product: [Plasma] plasma-nm Reporter: Joshua Makler <jmakler41>
Component: editorAssignee: Jan Grulich <jgrulich>
Status: RESOLVED WORKSFORME    
Severity: normal CC: aspotashev, kde, nate, ongun.kanat, pfyu817
Priority: NOR    
Version: 5.17.3   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In: 5.17.5
Attachments: Screenshot of the bug described
The context menu location is as if the client area starts from (0, 0)
attachment-5490-0.html
QOwnCloud context menu

Description Joshua Makler 2019-12-02 19:38:57 UTC
Created attachment 124277 [details]
Screenshot of the bug described

SUMMARY
when accessing "configure network connections" from right click on taskbar, and then right clicking a connection the dialog box will open on the left of the screen instead of under the mouse. minimizing and reopening temporarily fixes it

STEPS TO REPRODUCE
1. right click on network icon in taskbar
2. select Configure Network connections
3. right click any network connection

OBSERVED RESULT
Dialog opens at far left of screen instead of under mouse.x, mouse.y. temporarily fixed for current instance if minimized and reopened

EXPECTED RESULT
Dialog box should be under mouse cursor

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: Arch linux 
(available in About System)
KDE Plasma Version: 5.17.3 -- bug began to appear around 5.17
KDE Frameworks Version: 5.64.0
Qt Version: 5.13.2

ADDITIONAL INFORMATION
Originally I had planned to fix the bug myself as I am a C++ programmer and wanted to contribute to the project. After digging deep into plasma-nm source and finding the related lines of code in file  /plasma-nm-master/kcm/qml/ConnectionItem.qml lines 148-155 and reading the related QML documentation, I discovered that nothing seemed to be amiss in the source to plasma-nm itself and that actually this bug is rooted deeper inside of Plasma-5 or QML itself and that I would unfortunately not be able to fix it and push a commit myself to help out (I deeply wanted to help though).

I also had other users of version 5.17+ replicate the bug for me on discord as part of testing.

because minimizing and reopening the window temporarily fixes it for a single instance, I have suspicions that something is causing mouse.x and mouse.y to return the wrong values when the window is first opened -- although simply losing focus on the window does not temporarily fix it the same way as minimizing. I am unsure if hoverEnabled: true source code behavior is involved. All I know is that all appears to be well within plasma-nm itself and that this issue is not specific to arch, but versions 5.17.0 and up.

I truly wanted to fix this bug for you guys myself and contribute it and have done everything in my power to investigate. but at this point it would require searching through the entire KDE -- and possibly QT/QML source code itself.

I know this is a lot of text, but I truly hope my research into this bug is helpful in fixing it.

if there is any way I can help, or any further information I can provide, please email me anytime at jmakler41@gmail.com and I would be more than happy to help. Hopefully one day I can make a contribution.

I have attached a screenshot of the behavior.
Comment 1 Joshua Makler 2019-12-02 20:05:15 UTC
*appears to be well within Plasma itself, not plasma-nm. sorry about that typo in additional information
Comment 2 David Edmundson 2019-12-03 10:12:05 UTC
Can't reproduce. (Qt 5.14 + kde master)

Are you on X or wayland?

If you move the window and right click is the new location different?
Uf you select a different item in the list is the popup location different?
Comment 3 Peifeng Yu 2019-12-03 16:40:22 UTC
Created attachment 124296 [details]
The context menu location is as if the client area starts from (0, 0)

I can reproduce on Archlinux with the latest packages. I'm on X.

Moving the window does not change the context menu location. But clicking on different locations within the same item, or different items changes the context menu location relatively.

In fact, I noticed that if you move the window to the top left corner, with the client area starting from (0, 0), then the context menu location is correct.
Comment 4 Peifeng Yu 2019-12-03 16:41:43 UTC
My versions:

Qt 5.13.2
Plasma 5.17.3
Comment 5 Joshua Makler 2019-12-04 13:38:23 UTC
Created attachment 124310 [details]
attachment-5490-0.html

I apologize for the delay in response.

I also am on X11 and unfortunately was not able to test on wayland on this
machine.

On Tue, Dec 3, 2019 at 11:41 AM Aetf <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=414762
>
> --- Comment #4 from Aetf <7437103@gmail.com> ---
> My versions:
>
> Qt 5.13.2
> Plasma 5.17.3
>
> --
> You are receiving this mail because:
> You reported the bug.
Comment 6 Joshua Makler 2019-12-04 13:41:38 UTC
(In reply to Joshua Makler from comment #5)
> Created attachment 124310 [details]
> attachment-5490-0.html
> 
> I apologize for the delay in response.
> 
> I also am on X11 and unfortunately was not able to test on wayland on this
> machine.
> 
> On Tue, Dec 3, 2019 at 11:41 AM Aetf <bugzilla_noreply@kde.org> wrote:
> 
> > https://bugs.kde.org/show_bug.cgi?id=414762
> >
> > --- Comment #4 from Aetf <7437103@gmail.com> ---
> > My versions:
> >
> > Qt 5.13.2
> > Plasma 5.17.3
> >
> > --
> > You are receiving this mail because:
> > You reported the bug.

moving it to the top left does seem to result in the popup being in the correct or close to correct place, however only while its in the top left corner.

aside from that, as i found, minimizing it fixes it anywhere on the screen for the single instance of program runtime.
Comment 7 Ongun Kanat 2019-12-12 15:52:21 UTC
Created attachment 124448 [details]
QOwnCloud context menu

I am experiencing a similar problem with QOwnCloud client. They might be related. I started experiencing after 5.17 update on ArchLinux. The current Qt version is 5.13.2 and frameworks version is 5.64.

Take a look at the attached video.

@Joshua Makler I think you forgot to change bug status from NEEDSINFO back to REPORTED since you've answered @David Edmundson's question.
Comment 8 Bug Janitor Service 2019-12-27 04:33:08 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 9 Christoph Feck 2019-12-27 16:09:33 UTC
New information was added starting with comment 3; changing status for inspection.
Comment 10 David Edmundson 2020-01-03 13:08:41 UTC
Git commit 5e055c1e1754971178ce8136417b07f1a2b71e5b by David Edmundson.
Committed on 03/01/2020 at 13:08.
Pushed by davidedmundson into branch 'Plasma/5.17'.

Port KCM menu away from PlasmaComponents

Summary:
Plasma's menu can't handle being in a nested window and opens in the
wrong place.

Porting to QQC resolves this, and we ideally shouldn't be using this
import within a KCM.

Test Plan:
Opened menu
It was in the right place
Clicking on delete still worked

Reviewers: #plasma, jgrulich

Reviewed By: jgrulich

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D26382

M  +11   -12   kcm/qml/ConnectionItem.qml

https://commits.kde.org/plasma-nm/5e055c1e1754971178ce8136417b07f1a2b71e5b
Comment 11 Christoph Feck 2020-01-04 00:16:21 UTC
Please add a comment when reopening bugs. Which version did you test? Which issues did you still see when testing?
Comment 12 Bug Janitor Service 2020-01-19 04:33:13 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 13 Bug Janitor Service 2020-02-03 04:33:18 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!