Closed Bug 568129 Opened 10 years ago Closed 10 years ago

[OOPP] alt-tab on full screen hulu or youtube freezes browser

Categories

(Core :: Plug-ins, defect)

1.9.2 Branch
x86
Windows XP
defect
Not set

Tracking

()

RESOLVED FIXED
Tracking Status
blocking1.9.2 --- .4+
status1.9.2 --- .4-fixed

People

(Reporter: jbecerra, Assigned: jimm)

References

Details

(Keywords: regression, verified1.9.2)

Attachments

(1 file)

While testing 3.6.4build5, when I play a hulu video in full screen and I press alt-tab the browser seems to escape full screen, but it freezes entirely. So far I have found that it doesn't happen on build4.

Steps:
1. Launch 3.6.4build5 and go to hulu
2. Play a video and click on the full screen icon
3. Press alt-tab

Expected: You can switch to another window, or simply get out of full screen mode

Actual: Browser freezes. No crash. No plugin crash.

I'm using Flash 10.0 r45 and several extensions. I'll try a plain installation just to make sure.
I see this as well using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4) Gecko/20100523 Firefox/3.6.4 ( .NET CLR 3.5.30729), Flash r45 and r53. 

On the blip.tv site I was not able to reproduce the issue yet. Don't really have any extensions installed except Java Console, Adobe DLM, and Microsoft.NET.
Works on nightly from 5/18, doesn't work on the one from 5/19:

http://hg.mozilla.org/releases/mozilla-1.9.2/pushloghtml?fromchange=61a692b7799f&tochange=daadd4051a15

Could be bug 563377
Keywords: regression
I see the behavior running the latest trunk nightly when I play a video on hulu.com, Win XP.
This problem doesn't seem to happen on Windows 7 (Flash 10.0 r45 or 10.1 rc) using 3.6.4build5.
Summary: [oopp] alt-tab on full screen hulu freezes browser → [OOPP] alt-tab on full screen hulu or youtube freezes browser
Confirmed with new profile.

URL http://www.youtube.com/watch?v=FEm8PZ_lUh8

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.5pre) Gecko/20100524 Namoroka/3.6.5pre ID:20100524042158
Regression window for 1.9.2:

Works(No hung):
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/4cc2d2bb15ec
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100518 Firefox/3.6.4 ID:20100518144213

Fails:
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/daadd4051a15
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.5pre) Gecko/20100519 Namoroka/3.6.5pre ID:20100519042210

Pushlog:
http://hg.mozilla.org/releases/mozilla-1.9.2/pushloghtml?fromchange=4cc2d2bb15ec&tochange=daadd4051a15

Regression window for 1.9.3:

Works:
http://hg.mozilla.org/mozilla-central/rev/2ea3130f9f7b
Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100518 Minefield/3.7a5pre ID:20100518111141

Fails:
http://hg.mozilla.org/mozilla-central/rev/d02a980b0d83
Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100518 Minefield/3.7a5pre ID:20100518114728

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2ea3130f9f7b&tochange=d02a980b0d83

Candidate regression bug:
Bug 566610  - [OOPP]Can not start scroll page by mouse wheel when mouse cursor is over a flash object 


And I confirm, if I disabled OOPP then the issue is gone. So, it is OOPP problem.
Blocks: 566610
Can we catch this in a debugger and figure out what's going on here?

We can't ship with alt-tab broken on Hulu; I was sure that was a test case we'd covered a bunch, though, so I'm a little surprised that it only came up today. Guessing we were only testing Windows 7?
Assignee: nobody → jmathies
blocking1.9.2: ? → .4+
I can reproduce on Windows XP SP3 too.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4) Gecko/20100523 Firefox/3.6.4 ID:20100523185824
(In reply to comment #7)
> Can we catch this in a debugger and figure out what's going on here?
> 
> We can't ship with alt-tab broken on Hulu; I was sure that was a test case we'd
> covered a bunch, though, so I'm a little surprised that it only came up today.
> Guessing we were only testing Windows 7?

Currently looking into this...
This scenario was very specifically tested, see https://bugzilla.mozilla.org/show_bug.cgi?id=563377#c61.

I tested it on a trybuild for bug 563377 on Windows XP. It looks like I didn't test it again after final checkin. I was waiting for the official build for final verification and then didn't test it yet since we got builds in the last two days when I was on jury duty.
So is this really bug 563377?
(In reply to comment #11)
> So is this really bug 563377?

bug 563377 landed a large change that used reply message on a number of events in a global hook. That caused some regressions, particularly bug 566610. That original fix, with certain hardware scenarios, didn't address the original problem. The follow up patch in bug 563377 addressed this by delaying reply message for focus until after flash had processed the event. That finally addressed the hang for WM_KILLFOCUS. Bug 566610 ended up removing the original hook solution for everything except the kill focus event.

This bug is similar, although the hang appears to be on a different, subsequent  event. In local release builds the original fix seemed to address the problem, but it looks like our optimized release builds have slightly different behavior.
That makes me feel better about how it slipped through, to be sure; any ideas on the next steps?
(In reply to comment #13)
> That makes me feel better about how it slipped through, to be sure; any ideas
> on the next steps?

I just pushed something to try. Based on some reverse debugging, the script evaluate flash does that locks up the browser can occur on more than one message. The good news is it always seems to happen at some point and only happens once during the full screen window's tear down. So rather than expect the eval right  after wm_killfocus is delivered to the hook, I just expect that it will happen at some point after.

Basically, I've removed this reset of the flag on subsequent events - 

http://mxr.mozilla.org/mozilla-central/source/dom/plugins/PluginModuleChild.cpp#1929
Ok, opt builds from try with the new fix. Anyone experiencing this, please take these for a spin!

http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/jmathies@mozilla.com-16a9b3b8de34/tryserver-win32/
Good news: alt-tab'ing from full screen now switches windows and escapes the full screen mode as expected.

Bad news: ctrl-tab or ctrl-l while video is playing doesn't respond, whether mouse hovers over video, or elsewhere in the page.
I've tried a few more times and using the keyboard combinations responds when playing videos in youtube, consistently, and I saw it happen on hulu, but I can't see when it happens. It depends on mouse focus, though.
(In reply to comment #16)
> Good news: alt-tab'ing from full screen now switches windows and escapes the
> full screen mode as expected.

That is good news.

> Bad news: ctrl-tab or ctrl-l while video is playing doesn't respond, whether
> mouse hovers over video, or elsewhere in the page.

With ctrl-tab I get yellow borders on flash controls when the video has focus. If the page has focus I switch tabs. Ctrl-l, focus to the address bar w/page focus, nothing with video focus. Both seem the same with ipc enabled/disabled. I'd suggest filing OOPP bugs if you find something peculiar with OOPP.
Attached patch patchSplinter Review
Attachment #447650 - Flags: review?(bent.mozilla)
Using the Build in Comment 15 on Win XP hardware I see the issue resolved with Alt-Tab and Fullscreen.

The Ctrl-l and Ctrl-Tab issues are trickier, and I do see the same thing Jim does in Comment 18 with youtube videos - when I ctrl-tab I do get yellow borders on youtube.com. On hulu.com I did not see them. But I am also having troubles with this machine freezing (CPU spikes) when testing so it makes it difficult to really gauge what is going on. I would suggest some QA lab testing on the Win XP machine to explore the Ctrl-l and Ctrl-Tab issue further.
Comment on attachment 447650 [details] [diff] [review]
patch

Tricky!
Attachment #447650 - Flags: review?(bent.mozilla) → review+
http://hg.mozilla.org/mozilla-central/rev/8645d782a8d5
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Attachment #447650 - Flags: approval1.9.2.4?
Comment on attachment 447650 [details] [diff] [review]
patch

The ctrl-tab/ctrl-l issues are unrelated - that's the Flash Player eating those keystrokes and, in some cases, doing something with them.

a=beltzner for mozilla-1.9.2 default and relbranch (GECKO1924_20100413_RELBRANCH)
Attachment #447650 - Flags: approval1.9.2.4? → approval1.9.2.4+
Tried 3.6.4b6 and trunk on XP and Win7, Flash 10.0 r45 and 10.1 rc6, hulu and yahoo sites, and alt-tab'ing when in full screen doesn't freeze the browser any more.
Keywords: verified1.9.2
youtube sites, I meant.
Just noticed that my comment #16 was really about ctrl-t (and for some mental lapse I wrote ctrl-tab - ctrl-t opens a new tab).
You need to log in before you can comment on or make changes to this bug.