Bug 301106

Summary:	Wrong _NET_WM_WINDOW_TYPE(ATOM) at dialogs
Product:	[Plasma] plasmashell	Reporter:	Alexander Tkachenko <alexyecu>
Component:	general	Assignee:	David Edmundson <kde>
Status:	RESOLVED FIXED
Severity:	normal	CC:	4k1r4.rulez, a.samirh78, kde, nate, noahadvs, plasma-bugs
Priority:	NOR	Keywords:	triaged
Version:	5.19.4
Target Milestone:	1.0
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	plasma panel "Dialog" or "Dropdown" in question

Description Alexander Tkachenko 2012-06-03 13:23:23 UTC

Wrong _NET_WM_WINDOW_TYPE(ATOM) at dialogs.
IS: _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
Should be: _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG
Tiling window managers works wrong (tiling, not making float) with these dialogs, cause their wrong _NET_WM_WINDOW_TYPE(ATOM).

Reproducible: Always

Steps to Reproduce:
1. Start coping (moving, extracting) of big folder or file, to see the dialogue.
2. Use xprop at dialogue, watch the output.
3. If you are using any tiling wm, watch the tiled dialogue even if your wm set to make dialog floating.
Actual Results:  
Tiling window managers works wrong (tiling, not making floating) with dolphin`s dialogs.

Expected Results:  
Floating dialogs in tiling wm`s.

Comment 1 Alexander Tkachenko 2012-06-13 05:51:59 UTC

I`ve got some advises at unixforum.org (popular russian site about for nix-like systems users):
1. To change not type, but role, like 'roster' in im`s. Dolphin`s windows have no role now.
2. To make titles looking like «coping» but not like «coping (7MiB of 12GiB)» or «coping 12%».

Comment 2 Nate Graham 2018-04-25 20:36:11 UTC

Which dialogs? And is this still an issue in KDE Frameworks 5.45?

Comment 3 Andrew Crouthamel 2018-09-28 03:23:36 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 set the bug status 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 4 Andrew Crouthamel 2018-10-29 02:10:32 UTC

Dear Bug Submitter,

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!

Comment 5 4k1r4.rulez 2020-07-28 18:47:05 UTC

This is still a valid bug in Framework 5.72
Missing correct _NET_WM_WINDOW_TYPE on different plasma items. 
What makes it worse is that everything related to plasma has same WM_CLASS "plasmashell" and _NET_WM_NAME "Plasma". Thus making different elements indistinguishable.

Comment 6 David Edmundson 2020-07-29 08:52:22 UTC

I still don't know which dialog you are referring to.

Can you include a screenshot

Comment 7 4k1r4.rulez 2020-07-29 09:30:30 UTC

Created attachment 130479 [details]
plasma panel

xproping on panel

Comment 8 4k1r4.rulez 2020-07-29 09:59:31 UTC

Sorry last reply was sent by mistake.

By dialogs I mean the dropdowns that are open when clicking on some elements in plasma. For example Status and Notifications widget.
This widget TYPE is identified as _KDE_NET_WM_WINDOW_TYPE_OVERRIDE
As far as I can see from the code this is `indicates a toplevel menu (AKA macmenu)...`. 
And this creates multiple problems:
1. Using anything but KWin (awesomeWM for example) is buggy because one can't make rules to properly place this "menus" on the screen. Plasma without KWin failing to do it by itself most of the time.
2. this "dialogs" are also the widget selector sidebar for example. It is TYPE'd as "DOCK" hence it acting as "DOCK" and not allowing focus thus effectively not allowing input which denies using of the search bar. 

This problem is with any "dropdown" or "dialog" that plasma is using. It's either TYPE'd incorrectly or have custom TYPE which provides nothing outside of kframeworks

Comment 9 4k1r4.rulez 2020-07-29 11:36:54 UTC

Created attachment 130483 [details]
"Dialog" or "Dropdown" in question

This is the "dialog" in question
As you can see it also not placed properly

Comment 10 David Redondo 2020-07-29 12:17:02 UTC

Info was my provided

Comment 11 Noah Davis 2023-08-10 20:03:10 UTC

It appears that the original report and the comment from 4k1r4.rulez may be about different bugs.

For the original bug, I tried copying a folder to see a dialog, and looked at its atoms with xprop. The dialog has `_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG, _NET_WM_WINDOW_TYPE_NORMAL`, which seems fine.

For 4k1r4.rulez's bug, I looked at the system tray's popup with xprop. The system tray has `_NET_WM_WINDOW_TYPE(ATOM) = _KDE_NET_WM_WINDOW_TYPE_APPLET_POPUP`, which I don't necessarily see an issue with. It's not a standard dialog, nor is it a normal window, it's a shell popup.

Since the original bug report seems to be about actual dialog windows, I'm marking this as fixed.