Closed Bug 591154 Opened 14 years ago Closed 14 years ago

Quakelive flickers in fullscreen mode

Categories

(Core :: Widget: Win32, defect)

Product:
Core
Component:
Widget: Win32
Platform:
All
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- final+

People

(Reporter: matjk7, Assigned: jimm)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(1 file)

fix
2.48 KB, patch
roc
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b5pre) Gecko/20100825 Minefield/4.0b5pre
Build Identifier: 

This looks a lot similar to bug 589864, however I was only able to reproduce it with the Quakelive plugin and in fullscreen mode.

Reproducible: Always

Steps to Reproduce:
1.Go to http://www.quakelive.com/#home
2.Join/start a match in fullscreen mode
Actual Results:  
Screen flickers and the game becomes unresponsive.

Expected Results:  
Quakelive should behave normally.

I have a feeling this is a regression from bug 575870.
Keywords: regression, regressionwindow-wanted
Version: unspecified → Trunk
So this is not the same as the flash flicker bug?
(In reply to comment #1)
> So this is not the same as the flash flicker bug?

Not really since that was with windowed plugins only and Quakelive is windowless. This also only happens in fullscreen. Perhaps the fix from bug 589864 was actually what regressed this?
Hmm, wish I could test but quakelive isn't working for me.
I haven't tried to setup an account myself either yet to see what you mean.
blocking2.0: --- → ?
This regressed between 08-24 (http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010-08-24-04-mozilla-central/) and 08-25 nightly (http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010-08-25-06-mozilla-central/). Pushlog is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9a623cc1c5e7&tochange=4a6ee9e82945
Disable remote XUL is in there too, but I still think it was bug 575870 since this bug doesn't happen if you enter fullscreen (f11) mode in firefox before launching Quakelive. (Just to be clear if my previous comments weren't, this happens when Quakelive is in fullscreen mode but firefox isn't. If both QL and firefox are in fullscreen mode or both are in windowed mode, there's no bug at all).
Jim, could the new titlebar code somehow prevent plugins from grabbing mouse focus when the plugin is fullscreen but firefox isn't?
(In reply to comment #5)
> This regressed between 08-24
> (http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010-08-24-04-mozilla-central/)
> and 08-25 nightly
> (http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010-08-25-06-mozilla-central/).
> Pushlog is:
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9a623cc1c5e7&tochange=4a6ee9e82945
> Disable remote XUL is in there too, but I still think it was bug 575870 since
> this bug doesn't happen if you enter fullscreen (f11) mode in firefox before
> launching Quakelive. (Just to be clear if my previous comments weren't, this
> happens when Quakelive is in fullscreen mode but firefox isn't. If both QL and
> firefox are in fullscreen mode or both are in windowed mode, there's no bug at
> all).
> Jim, could the new titlebar code somehow prevent plugins from grabbing mouse
> focus when the plugin is fullscreen but firefox isn't?

Don't see how, although I'm confused as to why this has to do with mouse capture?
(In reply to comment #6)
> Don't see how, although I'm confused as to why this has to do with mouse
> capture?

The first time the plugin is loaded (both in Chrome and firefox when it worked) the screen flickers once when attempting to grab mouse focus. Right now the screen just flickers over and over again, and the mouse arrow is shown during that (it should show a crosshair instead), at least giving the impression that it's failing to grab mouse focus.
Keywords: regressionwindow-wanted
Any idea felipe? I think we mucked with mouse capture for the original landing of the titlebar work.
I can't reproduce it on my machine (I did set quakelive to fullscreen mode). Matheus, what system style are you using: aero basic? And is it Win7 64 bits or 32?

Bug 575870 means that we have mCustomDrawing for classic/aero basic too, right? (and thus we handle the hittest)
A wild guess would be the nsToolkit::MouseTrailer which fires a lot of WM_NCHITTEST messages. I've seen some other weird bugs related to that.
Aero glass on Win7 32 bits. A weird thing I noticed is that if I have firefox open and try to launch the game in Chrome it doesn't grab mouse focus either.
This *might* be a known Quakelive issue: http://www.quakelive.com/forum/showthread.php?948-Grey-Screen-as-game-tries-to-start. Apparently this also happens in Firefox 3.6 and even in IE, but it seems very odd that bug 575870 triggers this for me, since I don't have any of known causes for this bug (i.e a OpenGL incompatible card) and using builds before the landing of bug 575870 work just fine.
If there's an easy workaround for this I believe it should be fixed, but otherwise feel free to close this as invalid.
Matheus, does the issue still happen if you enable the menu bar?
(In reply to comment #12)
> Matheus, does the issue still happen if you enable the menu bar?

No, enabling the menu bar "fixes" this.
This sounds like a bug on our end then. I can't reproduce but if you're willing let's try to track this down. Could you test this build and see if the problem happens: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/felipc@gmail.com-0acc227053cf/tryserver-win32/

As the main suspect is mouse capture the only difference in this build is that I removed the custom hittest JS event to see if it makes a difference
(http://hg.mozilla.org/try/rev/0acc227053cf)
Unfortunately that build didn't fix this issue. But I think I have an idea as to why I'm hitting this bug and you are not.

Basically whenever I play Quakelive my Aero theme changes to basic (bug 545892) and the message from system tray seems to take away focus from the plugin. Since whenever the plugin focus is lost the Aero theme resets to glass, the next time I try to focus on the plugin bug 545892 strikes again and focus is lost again.
So unless it's possible to ignore OS notifications when plugins are fullscreen I think the only way to fix this is to fix bug 545892.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: nobody → felipc
Matheus, bug 545892 has been fixed on this weekend's nightly builds. Can you give it a try and see if this problem was fixed as well?
(In reply to comment #16)
> Matheus, bug 545892 has been fixed on this weekend's nightly builds. Can you
> give it a try and see if this problem was fixed as well?

Still seeing this with a new profile in Firefox and default settings in QL.

If you can't reproduce this, is there anything I can do to help here? (Like running a debug build or something).
(In reply to comment #18)
> Matheus, can you try jimm's tryserver build which has a follow-up patch from
> bug 545892:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/jmathies@mozilla.com-3819aa8a97cc/tryserver-win32/

That build does fix bug 545892 completely (as far as I could test), but it doesn't fix this bug unfortunately.
(In reply to comment #0)

> Screen flickers and the game becomes unresponsive.
> 
> Expected Results:  
> Quakelive should behave normally.
> 
> I have a feeling this is a regression from bug 575870.

Is the flickering the problem where full screen seems to kick in and then turn off repeatedly? Making it hard to get back to your desktop without thrashing about quite a bit?
(In reply to comment #20)
 
> Is the flickering the problem where full screen seems to kick in and then turn
> off repeatedly? Making it hard to get back to your desktop without thrashing
> about quite a bit?

Yes.
Assignee: felipc → jmathies
I was thinking this might have been similar to bug 566135, but disabling trim on minimize didn't help. This seems like some sort of focus related issue where we're fighting with the game. I don't see why this would be the new title bar code since it's not related to focus. But I'll dig into the regression range and see if I can pin something down.
Cool, thanks Jim. Yeah it does look like focus issues. Just a reminder that with the menubar on the problem doesn't happen (as reported by OP), so maybe it's some messages sent by the OS or Quakelive only when the app is drawing in the NC area.

Did you manage to reproduce it?
(In reply to comment #23)
> Cool, thanks Jim. Yeah it does look like focus issues. Just a reminder that
> with the menubar on the problem doesn't happen (as reported by OP), so maybe
> it's some messages sent by the OS or Quakelive only when the app is drawing in
> the NC area.
> 
> Did you manage to reproduce it?

Yeah just confirmed it. It was the titlebar landing for some reason. 

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9a623cc1c5e7&tochange=4a6ee9e82945
Blocks: 607326
Attached patch fix — — Splinter Review 
Tricky tricky. Full screen shuts down aero, that triggers a dwm composition changed event -> NS_THEMECHANGED ->  PresShell call Invalidate on the theme module -> nsUXThemeData::UpdateTitlebarInfo() -> ShowWindow -> QuakeLive's window loses foreground status. 

QL really shouldn't be fighting with us over foreground status. That's a deficiency in their code that results in the loop that causes the desktop to become unresponsive.
Attachment #486075 - Flags: review?(roc)
Flags: in-litmus?
http://hg.mozilla.org/mozilla-central/rev/770046fa622d
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
sorry if wrong,

http://forums.mozillazine.org/viewtopic.php?p=10098821#p10098821
(caption button issue) is caused by this checkin ?
Depends on: 610201
Flags: in-litmus?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: