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

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[juan becerra [:juanb]]

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.

Comment 1

[Marcia Knous [:marcia]]

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.

Comment 2

[juan becerra [:juanb]]

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

Comment 3

[Marcia Knous [:marcia]]

I see the behavior running the latest trunk nightly when I play a video on hulu.com, Win XP.

Comment 4

[juan becerra [:juanb]]

This problem doesn't seem to happen on Windows 7 (Flash 10.0 r45 or 10.1 rc) using 3.6.4build5.

Comment 5

[Alice0775 White]

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

Comment 6

[Alice0775 White]

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.

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

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?

Comment 8

[Alice0775 White]

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

Comment 9

[Jim Mathies [:jimm]]

(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...

Comment 10

[Al Billings [:abillings - ex-MoCo]]

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.

Comment 11

[Al Billings [:abillings - ex-MoCo]]

So is this really bug 563377?

Comment 12

[Jim Mathies [:jimm]]

(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.

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

That makes me feel better about how it slipped through, to be sure; any ideas on the next steps?

Comment 14

[Jim Mathies [:jimm]]

(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

Comment 15

[Jim Mathies [:jimm]]

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/[e-mail]-16a9b3b8de34/tryserver-win32/

Comment 16

[juan becerra [:juanb]]

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.

Comment 17

[juan becerra [:juanb]]

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.

Comment 18

[Jim Mathies [:jimm]]

(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.

Comment 19

[Jim Mathies [:jimm]]

Attachment: patch

Comment 20

[Marcia Knous [:marcia]]

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 21

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Comment on attachment 447650 [details] [diff] [review]
patch

Tricky!

Comment 22

[Jim Mathies [:jimm]]

http://hg.mozilla.org/mozilla-central/rev/8645d782a8d5

Comment 23

[Mike Beltzner [:beltzner, not reading bugmail]]

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)

Comment 24

[Jim Mathies [:jimm]]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/485a0b292661
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/41807e6bcb14

Comment 25

[juan becerra [:juanb]]

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.

Comment 26

[juan becerra [:juanb]]

youtube sites, I meant.

Comment 27

[juan becerra [:juanb]]

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).