GNOME Bugzilla – Bug 441786
locks keyboard but not screen while applications are fullscreen
Last modified: 2008-07-17 17:52:03 UTC
Please describe the problem: If Firefox is fullscreen (F11) and Typing break time comes, screen does not lock. Keyboard stops working but mouse still moves and I can press on links etc. When I exit firefox fullscreen, screen locks (or, actually, locked screen image surfaces). Steps to reproduce: 1. Open Firefox in fullscreen 2. Wait for typing break Actual results: Screen does not lock, keyboard stops working Expected results: Lock screen, as usual Does this happen every time? yes Other information: I'm using Firefox 2.0.0.3, Ubuntu Feisty
Happens with full-screen openoffice as well.
*** Bug 501762 has been marked as a duplicate of this bug. ***
Dup is with terminal.
Created attachment 113606 [details] [review] make a break windwow modal I offer this patch.
Thanks! 2008-07-02 Jens Granseuer <jensgr@gmx.net> Patch by: Andrey Gusev <ronne@list.ru> * drw-break-window.c: (drw_break_window_init): make the typing break window modal so it properly locks the screen when apps like firefox are running in fullscreen mode (bug #441786)
Created attachment 114034 [details] [review] Better patch I didn't get mail by this bug, so I didn't now about committing previous patch. I use package with it and notes that screen blinks, before appearing a break window. I think, making window modal before showing it, is not correct. The new patch makes window modal after showing, in this case screen don't blink.
Can you explain what you mean by blinking screen? I did not see bad behaviour when I tested the patch. (In reply to comment #6) > I didn't get mail by this bug, so I didn't now about committing previous patch. That is because you do not get added to the CC list when you just add an attachment. Did that now.
It looks like clear screen and show window after this. I have gnome composite option enabled and Intel video card. So, about most function is written, that it can be used before showing window, but it isn't written about "gtk_window_set_modal". It is not very noticeably.
Yes, you can make a window modal before showing it. The behaviour you describe sounds more like a problem in the driver/X stack or the window manager. Programmatically, your first patch is "more correct", so if this isn't very noticable I'd prefer to leave it as is.