Bug 283030 - Toolbar appears above all windows when deattached from main window
Summary: Toolbar appears above all windows when deattached from main window
Status: RESOLVED DUPLICATE of bug 311768
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: kdeui (show other bugs)
Version: 0.1
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-29 12:24 UTC by artem
Modified: 2015-12-28 16:13 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
The kontact/mail toolbar is above the active konsole window (89.25 KB, image/png)
2011-09-29 12:24 UTC, artem
Details
Outout of `xprop` (1.44 KB, text/plain)
2011-09-29 14:36 UTC, artem
Details
Outout of `xprop -id` (29.62 KB, text/plain)
2011-09-29 14:37 UTC, artem
Details

Note You need to log in before you can comment on or make changes to this bug.
Description artem 2011-09-29 12:24:46 UTC
Created attachment 64066 [details]
The kontact/mail toolbar is above the active konsole window

Version:           4.4.10 (using KDE 4.6.5) 
OS:                Linux

I deattached the toolbar of the mail component. And after click on Trash button the toolbar appears above any another window, even when Kontact window is minimized.

I can reproduce the bug by attaching and deattaching the toolbar again in mail component. But there is no such problem in the calendar component and in a separate kmail instance.

Reproducible: Always

Steps to Reproduce:
1. Unlock and deattach the toolbar in mail component.
2. Lock the toobar.
3. Switch to another window then back to kontact.
4. Remove some email by clicking on Trash toolbar button.
5. Switch to another window again.

Actual Results:  
The toolbar is still shown above the window.

Expected Results:  
The toolbar should be hidden unless I switched back to kontact window.

OS: Linux (i686) release 2.6.38-11-generic
Compiler: cc
Kubuntu
KDE updated from PPA repository (http://ppa.launchpad.net/kubuntu-ppa/ppa/ubuntu natty main)
Comment 1 Thomas Lübking 2011-09-29 14:20:16 UTC
open konsole, 

call "kcmshell4 kwinoptions", enter the last tab - is "hide utility windows..." checked?

call "xprop > nasty_tool.txt" and click the nasty toolbar.

call "xprop | grep TRANSIENT" and click it again

The last item in the output should be a hexadecimal number ("0x123456"), we'll name it "<hex_num>", last

call "xprop -id <hex_num> > nasty_tool_leader.txt" (only the last '>' is really a '>' - the rest is part of the number figured above)

and attach nasty_tool.txt and nasty_tool_leader.txt to the bug
Comment 2 artem 2011-09-29 14:36:28 UTC
Created attachment 64073 [details]
Outout of `xprop`
Comment 3 artem 2011-09-29 14:37:24 UTC
Created attachment 64074 [details]
Outout of `xprop -id`
Comment 4 artem 2011-09-29 14:37:52 UTC
> call "kcmshell4 kwinoptions", enter the last tab - is "hide utility windows..."
checked?

Yes

> and attach nasty_tool.txt and nasty_tool_leader.txt to the bug

Done
Comment 5 Thomas Lübking 2011-09-29 14:57:30 UTC
The windows look ok.

- Can you raise konsole above the toolbar?
- Is the toolbar interactive (ie. does it react on clicking icons _w/o_ activating the kontact mainwindow first?
- Does it happen with compositing suspended? (shift+alt+f12)
- Does it happen with other UI styles (eg. "kontact --style plastique")?
- Do you use tabbing and/or tiling features of kwin?
Comment 6 artem 2011-09-29 15:10:02 UTC
> - Can you raise konsole above the toolbar?

No. Even if I activate the "always on top" feature.

> - Is the toolbar interactive (ie. does it react on clicking icons _w/o_
> activating the kontact mainwindow first?

Yes, it's interactive and works well even when the kontact window is minimized. And the toolbar is shown on all desktops and rooms.

> - Does it happen with compositing suspended? (shift+alt+f12)

Yes. No changes when I suspend compositing.

> - Does it happen with other UI styles (eg. "kontact --style plastique")?

Yes

> - Do you use tabbing and/or tiling features of kwin?

No

The toolbar is still there even after restarting kontact.
Comment 7 artem 2011-09-29 15:15:20 UTC
Maybe this is related somehow.

If I unlock the toolbar and click a button on it, it appears locked again. However the context menu item shows that it's not locked still. So I have to lock and unlock again to make it possible to move the toolbar.
Comment 8 artem 2011-09-29 17:43:44 UTC
The problem had disappeared when I unlocked and moved the toolbar. And I was not able to reproduce the bug. However it returned just after restarting kontact.
Comment 9 Thomas Lübking 2011-09-29 22:28:43 UTC
Interesting. I get the very same with konqueror when changing tabs.

The toolbar is hidden and reshown with the tab switch (since it's somehow virtually part of that tab) and looses the locking representation (just as you mentioned - but that is a client issue only, ie. ktoolbars fault) and also sticks above the desktop.... well, at least i can add some debug code to watch what's going on there ;-)
Comment 10 artem 2011-09-29 22:45:38 UTC
Great. I just tried and have got exactly same problem in konqueror. And I have two sticky toolbars now! :)

Good luck with debugging!
Comment 11 Thomas Lübking 2011-09-30 18:22:25 UTC
Ok, i know what's going on but it's likely a client bug (will test the client side next)

When changing tabs in konqueror, the toolbar receives an upmap request and is released by kwin but never gets a following maprequest when remapped - thus remains completely unmanged by kwin what likely means it uses the Qt::X11BypassWindowManagerHint (or there'd be a major problem with event processing)
Comment 12 Thomas Lübking 2011-09-30 21:22:32 UTC
Filtering QEvent::Show shows that "widget->windowFlags() & Qt::X11BypassWindowManagerHint" is true when
a) the toolbar is dragged out (expectable - likely a Qt thing and ok, since the toolbar is re-shown w/o this flag)
b) the toolbar is withdrawn and re-shown when switching tabs in konqueror (i expect the very same to happen for kontact but maybe other causes)

As a result of (b) the toolbar is not considered by kwin when de/activating the main window. This is not a kwin bug, since the window maps directly, bypassing the WM as the set flag suggests.

-> Reassigning & confirming.
Comment 13 Thomas Lübking 2011-09-30 21:23:34 UTC
forgot to reset the mail assignment ... :S
Comment 14 artem 2012-02-28 00:28:47 UTC
Does it make sense to change the status from NEW to OLD ? :)
Comment 15 Christoph Feck 2013-07-08 03:00:49 UTC

*** This bug has been marked as a duplicate of bug 311768 ***