awesome

Welcome to awesome bug tracking system.
Tasklist

FS#762 - mozplugger freezes desktop (works in wmii)

Attached to Project: awesome
Opened by vijayender (vijayender) - Wednesday, 05 May 2010, 12:45 GMT
Last edited by Uli Schlachter (psychon) - Sunday, 25 November 2012, 14:46 GMT
Task Type Bug Report
Category Core
Status Researching
Assigned To No-one
Operating System Linux
Severity Medium
Priority Normal
Reported Version 3.4.4
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 7
Private No

Details

On opening a pdf with mozplugger say using okular in a chromium-bin,
it all works fine until you click in the embedded window. Once you have clicked
the embedded window in the browser, mouse and keyboard deliver no more events.
If you don't click the embedded window, you can even scroll the file and hovering
changes the buttons.

The only way to recover (for me) is to switch to a tty and kill browser.

The same setup works fine in wmii.
This task depends upon

Comment by Uli Schlachter (psychon) - Friday, 07 May 2010, 09:19 GMT
Can anyone else verify the same thing happens to him? Does anyone see sth similar with an easier test case?
Comment by Tibor Csögör (tibi) - Friday, 28 May 2010, 10:09 GMT
I can confirm this case. The same thing happens with Firefox/mozplugger and OpenOffice.org or Acrobat Reader. I guess this narrows it down to mozplugger.
Comment by Uli Schlachter (psychon) - Friday, 11 June 2010, 16:49 GMT
Reproducable here with a random pdf and xpdf. Killing xpdf made stuff work again for me (well, vimperator broke...).
Comment by Uli Schlachter (psychon) - Friday, 11 June 2010, 17:01 GMT
xtrace on awesome. Around 160.5 I clicked into the mozplugger window, those property notifies where coming in all the time, dunno why. At 172 I had pkill'd xpdf.
I'd say this looks like a server grab, but xlsclients works while the UI is frozen. :/

160.464 000:>:0f98: Event PropertyNotify(28) window=0x00600034 atom=0x13b(unrecognized atom) time=0x0068c759 state=NewValue(0x00)
160.504 000:>:0f98: Event PropertyNotify(28) window=0x00600034 atom=0x13b(unrecognized atom) time=0x0068c781 state=NewValue(0x00)
160.544 000:>:0f98: Event PropertyNotify(28) window=0x00600034 atom=0x13b(unrecognized atom) time=0x0068c7a9 state=NewValue(0x00)
160.584 000:>:0f98: Event LeaveNotify(8) detail=Nonlinear(0x03) mode=Normal(0x00) flags=same-screen time=0x0068c7bd root=0x00000111 event=0x00200004 child=None(0x00000000) root-x=1497 root-y=141 event-x=1497 event-y=141 state=0
160.584 000:>:0f98: Event EnterNotify(7) detail=NonlinearVirtual(0x04) mode=Normal(0x00) flags=same-screen time=0x0068c7bd root=0x00000111 event=0x00600034 child=0x006000d2 root-x=1497 root-y=141 event-x=1495 event-y=120 state=0
160.584 000:>:0f98: Event EnterNotify(7) detail=Nonlinear(0x03) mode=Normal(0x00) flags=same-screen time=0x0068c7bd root=0x00000111 event=0x00c0004f child=None(0x00000000) root-x=1497 root-y=141 event-x=1493 event-y=67 state=0
160.585 000:<:0f99: 12: Request(42): SetInputFocus revert-to=Parent(0x02) focus=0x00600034 time=CurrentTime(0x00000000)
160.585 000:<:0f9a: 44: Request(25): SendEvent propagate=false(0x00) destination=0x00600034 event-mask=0 ClientMessage(33) format=0x20 window=0x00600034 type=0x115("WM_PROTOCOLS") data=0x24,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00;
160.585 000:>:0f9a: Event LeaveNotify(8) detail=Inferior(0x02) mode=Normal(0x00) flags=same-screen time=0x0068c7d0 root=0x00000111 event=0x00c0004f child=None(0x00000000) root-x=1478 root-y=143 event-x=1474 event-y=69 state=0
160.585 000:>:0f9a: Event FocusIn(9) detail=Inferior(0x02) event=0x00600034 mode=Normal(0x00)
160.585 000:>:0f9a: Event FocusIn(9) detail=Pointer(0x05) event=0x00c0004f mode=Normal(0x00)
160.585 000:>:0f9a: Event FocusOut(10) detail=Inferior(0x02) event=0x00600034 mode=Normal(0x00)
160.949 000:>:0f9a: Event LeaveNotify(8) detail=Virtual(0x01) mode=Grab(0x01) flags=focus,same-screen time=0x0068c92a root=0x00000111 event=0x00c0004f child=0x00c00050 root-x=1211 root-y=183 event-x=1207 event-y=109 state=Button1
160.949 000:>:0f9a: Event EnterNotify(7) detail=Inferior(0x02) mode=Grab(0x01) flags=same-screen time=0x0068c92a root=0x00000111 event=0x00600034 child=None(0x00000000) root-x=1211 root-y=183 event-x=1209 event-y=162 state=Button1
160.949 000:>:0f9a: Event ButtonPress(4) button=left button(0x01) time=0x0068c92a root=0x00000111 event=0x00600034 child=0x006000d2 root-x=1211 root-y=183 event-x=1209 event-y=162 state=0 same-screen=true(0x01)
160.949 000:<:0f9b: 12: Request(42): SetInputFocus revert-to=Parent(0x02) focus=0x00600034 time=CurrentTime(0x00000000)
160.949 000:<:0f9c: 44: Request(25): SendEvent propagate=false(0x00) destination=0x00600034 event-mask=0 ClientMessage(33) format=0x20 window=0x00600034 type=0x115("WM_PROTOCOLS") data=0x24,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00;
160.949 000:<:0f9d: 24: Request(18): ChangeProperty mode=Replace(0x00) window=0x00000111 property=0xe9("_NET_CLIENT_LIST_STACKING") type=0x21("WINDOW") data=;
160.950 000:<:0f9e: 28: Request(18): ChangeProperty mode=Replace(0x00) window=0x00000111 property=0xe9("_NET_CLIENT_LIST_STACKING") type=0x21("WINDOW") data=0x00600034;
160.950 000:<:0f9f: 8: Request(35): AllowEvents mode=ReplayPointer(0x02)
160.950 000:<:0fa0: 20: Request(12): ConfigureWindow window=0x00200004 values={sibling=0x00000000 stack-mode=Above(0x00)}
160.950 000:<:0fa1: 20: Request(12): ConfigureWindow window=0x00600034 values={sibling=0x00200004 stack-mode=Above(0x00)}
160.950 000:>:0fa1: Event FocusIn(9) detail=Inferior(0x02) event=0x00600034 mode=Normal(0x00)
160.950 000:>:0fa1: Event PropertyNotify(28) window=0x00000111 atom=0xe9("_NET_CLIENT_LIST_STACKING") time=0x0068c93e state=NewValue(0x00)
160.950 000:>:0fa1: Event PropertyNotify(28) window=0x00000111 atom=0xe9("_NET_CLIENT_LIST_STACKING") time=0x0068c93e state=NewValue(0x00)
160.950 000:>:0fa1: Event LeaveNotify(8) detail=Inferior(0x02) mode=Ungrab(0x02) flags=focus,same-screen time=0x0068c93e root=0x00000111 event=0x00600034 child=None(0x00000000) root-x=1211 root-y=183 event-x=1209 event-y=162 state=Button1
160.950 000:>:0fa1: Event EnterNotify(7) detail=Virtual(0x01) mode=Ungrab(0x02) flags=focus,same-screen time=0x0068c93e root=0x00000111 event=0x00c0004f child=0x00c00050 root-x=1211 root-y=183 event-x=1207 event-y=109 state=Button1
160.950 000:>:0fa1: Event EnterNotify(7) detail=Inferior(0x02) mode=Grab(0x01) flags=focus,same-screen time=0x0068c93e root=0x00000111 event=0x00c0004f child=None(0x00000000) root-x=1211 root-y=183 event-x=1207 event-y=109 state=Button1
160.950 000:>:0fa1: Event ButtonPress(4) button=left button(0x01) time=0x0068c92a root=0x00000111 event=0x00c0004f child=0x00c00050 root-x=1211 root-y=183 event-x=1207 event-y=109 state=0 same-screen=true(0x01)
160.950 000:>:0fa0:Error 3=Window: major=12, minor=0, bad=0
172.980 000:>:0fa1: Event DestroyNotify(17) event=0x00000111 window=0x00c00043
Comment by Uli Schlachter (psychon) - Friday, 11 June 2010, 17:03 GMT
I just noticed that there is no reply to the ConfigureWindow at serial 0fa1...?!

Just for reference, here is the "rest" of the xtrace output (gonna close that terminal now and dont really feel like running this a second time):

160.950 000:>:0fa0:Error 3=Window: major=12, minor=0, bad=0
172.980 000:>:0fa1: Event DestroyNotify(17) event=0x00000111 window=0x00c00043
172.980 000:>:0fa1: Event DestroyNotify(17) event=0x00000111 window=0x00c00004
172.980 000:>:0fa1: Event DestroyNotify(17) event=0x00000111 window=0x00c00049
172.980 000:>:0fa1: Event DestroyNotify(17) event=0x00000111 window=0x00c00048
172.980 000:>:0fa1: Event UnmapNotify(18) event=0x00c0004f window=0x00c0004f from-configure=false(0x00)
172.980 000:>:0fa1: Event LeaveNotify(8) detail=Inferior(0x02) mode=Ungrab(0x02) flags=focus,same-screen time=0x0068f828 root=0x00000111 event=0x00c0004f child=None(0x00000000) root-x=1211 root-y=183 event-x=1207 event-y=109 state=Button1
172.980 000:>:0fa1: Event LeaveNotify(8) detail=Virtual(0x01) mode=Normal(0x00) flags=focus,same-screen time=0x0068f828 root=0x00000111 event=0x00c0004f child=0x00c00050 root-x=1211 root-y=183 event-x=1207 event-y=109 state=0
172.980 000:>:0fa1: Event EnterNotify(7) detail=Inferior(0x02) mode=Grab(0x01) flags=focus,same-screen time=0x0068f828 root=0x00000111 event=0x00600034 child=None(0x00000000) root-x=985 root-y=226 event-x=983 event-y=205 state=Button1
172.980 000:>:0fa1: Event ButtonPress(4) button=left button(0x01) time=0x0068cb0d root=0x00000111 event=0x00600034 child=0x006000d2 root-x=3 root-y=47 event-x=1 event-y=26 state=0 same-screen=true(0x01)
172.980 000:>:0fa1: Event DestroyNotify(17) event=0x00c0004f window=0x00c0004f
172.980 000:>:0fa1: Event DestroyNotify(17) event=0x00000111 window=0x00c00016
172.980 000:>:0fa1: Event DestroyNotify(17) event=0x00000111 window=0x00c00032
172.980 000:>:0fa1: Event DestroyNotify(17) event=0x00000111 window=0x00c00033
172.981 000:<:0fa2: 12: Request(42): SetInputFocus revert-to=Parent(0x02) focus=0x00600034 time=CurrentTime(0x00000000)
Comment by Uli Schlachter (psychon) - Friday, 11 June 2010, 17:40 GMT
Here's the xtrace on firefox (and the shitload of other apps it starts, xtrace captured 4 different clients).

No idea what exactly happens in there (or at which point the mouse click shows up), but it got to be in there.
   t (419.2 KiB)
Comment by Uli Schlachter (psychon) - Friday, 11 June 2010, 18:21 GMT
By now I figured out that an XEMBED_REQUEST_FOCUS is sent at 002:<:0023 (so client 2 is the embedding window).
At 001:>:e1af: the embedded window receives this request.

In response to this, client 001 requests its _XEMBED_INFO property. The property value is: Reply to GetProperty: type=0x118("_XEMBED_INFO") bytes-after=0x00000000 data=0xce4fce70,0x00000000;
This value seems quite invalid. JD: Any thoughts on that value?

xpdf then sends an XEMBED_FOCUS_IN with XEMBED_FOCUS_CURRENT. In response to this, the "other" client sends a generated FocusIn event with propagate=false.

After this I can't figure out what's going on. Some RENDER painting and... dunno, why does everything lock up?
Comment by Uli Schlachter (psychon) - Saturday, 12 June 2010, 06:34 GMT
I wonder if we should ask the mozplugger team for input. They got a bug tracker[1], but I dont feel like creating an account there. Any volunteers? ;)

[1] http://mozplugger.mozdev.org/bugs.html
Comment by Tibor Csögör (tibi) - Monday, 28 June 2010, 00:50 GMT
A workaround for Firefox (tested with version 3.6.4) is to press [TAB] (this activates the URL bar) and then [CTRL]+[T] to open a new tab -> focus handling is back to normal. Basically anything that switches to a different tab works.
Comment by Yaroslav Halchenko (yarikoptic) - Thursday, 15 July 2010, 22:24 GMT
For me evil workaround is switch to console and 'killall -HUP awesome'
[TAB] sounds like a cool one but didn't work for me with soffice since then TAB is processed by embedded soffice and jumps to next entry within it.
Comment by Yaroslav Halchenko (yarikoptic) - Thursday, 15 July 2010, 22:34 GMT
I can volunteer to create an account for you Uli on mozplugger -- or please provide a summary of the bug/issue in mozplugger so I could pass on... to me issue looks to reside in awesome though -- it is the one which gets locked up
Comment by Uli Schlachter (psychon) - Friday, 16 July 2010, 08:25 GMT
Awesome doesn't lock up (e.g. use notify-send to send a notification, it will work). It's just that something is grabbing all input and so nothing else gets anything. No idea why that only happens with awesome (anybody tried to reproduce this with dwm?).
Also, I already sent a mail to the mozplugger list, I think, but didn't get any reply. I don't know how they could help anyway, the embedding of subwindows is handled by code outside of mozplugger. :/
My mail to them basically only linked to this bug report, I don't have any more useful input.
Comment by Yaroslav Halchenko (yarikoptic) - Friday, 16 July 2010, 21:58 GMT
If it would be of help:

http://www.onerussian.com/Linux/bugs/awesome-lockup/awesome-xtrace-3.log
http://www.onerussian.com/Linux/bugs/awesome-lockup/wmaker-xtrace-1.log

in each case I opened .doc document within mozplugger inside firefox/icewasel.
Then I clicked ` (which doesn't lock things up) and immediately clicked mouse inside window which leads to problems on awesome but is fine on wmaker... then I tried Win-1 under awesome and Alt-1 under wmaker to switch to first "tag" (sure thing there were no effect on awesome).

So look for keycode=0x31 (of `). I also added human readable time stamps with ts for reference
Let me know if I could be of any more help
Comment by Uli Schlachter (psychon) - Saturday, 17 July 2010, 13:15 GMT
Whatever this bug is, it's not some kind of grab.

According to this, every grab is released again:
grep -i Grab * | grep -v 'Event EnterNotify' | grep -v 'Event LeaveNotify' | grep -v 'Event FocusIn' | grep -v 'Event FocusOut' | grep -v ': UngrabServer' | grep -v ': GrabServer'

One can find such a line in both outputs:
Reply to GetInputFocus: revert-to=None(0x00) focus=None(0x00000000)

This might cause this, dunno. Anyone knows how awesome reacts when nothing has the input focus?
Comment by Yaroslav Halchenko (yarikoptic) - Tuesday, 02 November 2010, 17:51 GMT
heh heh -- issue persists and we are in limbo space :-/
Comment by Yaroslav Halchenko (yarikoptic) - Tuesday, 02 November 2010, 17:58 GMT
one more observation -- if I open (even multiple) tabs with mozplugger content, then, before the evil grab, do killall -HUP awesome, after awesome's restart everything works smooth. So it is like something "bad" happens at the beginning of mozplugger embodiment into the window, and restart of awesome "resolves" it for future interactions with that window.
Similar thing that if I start multiple mozplugged tabs, lock by clicking in the menu of one of them, -HUP awesome, then everything (in all opened tabs) works fine.
Comment by Yaroslav Halchenko (yarikoptic) - Wednesday, 03 November 2010, 18:14 GMT
Moreover KDE shortcuts are handled just fine (I am running awesome as KDEWM with kde4), so I can Alt-F2 and enter "killall -HUP awesome"; which suggests indeed that nothing is per se locked globally but rather gets stuck at awesome (KDE shortcuts superseed awesome's)
Comment by Thomas Koch (thkoch2001) - Tuesday, 15 November 2011, 12:54 GMT
This bug is also reported for Debian[1] and mozplugger[2]. And I just got hit by it.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609215
[2] https://www.mozdev.org/bugs/show_bug.cgi?id=23600
Comment by Adrian Wheeldon (ARandomOWL) - Friday, 14 September 2012, 18:23 GMT
I still have this issue with Awesome 3.4.13, Firefox 15.0.1, epdfviewer, Arch Linux.
Comment by Dan Forest-Barbier (dpanth3r) - Sunday, 25 November 2012, 13:18 GMT
Same here, still getting freezes (have to switch to tty/ssh to kill the embedded pdf reader).
Debian (sid, AMD64), Awesome 3.4.13-1, Firefox 17.0 (from LinuxMint import repository), evince/xpdf/acroread:i386 all cause the bug.

I think this issue should at least get the “confirmed” status :)
Comment by Tim Y (tdy) - Tuesday, 27 November 2012, 19:15 GMT
seems to be fixed in git/master.. arch x86_64, firefox 17, okular/apvlv
Comment by Tim Y (tdy) - Tuesday, 27 November 2012, 22:00 GMT
as well as 3.5-rc1

Loading...