Closed Bug 1151318 Opened 9 years ago Closed 9 years ago

Browser UI becomes unresponsive state when using Unity Web Player Plugin

Categories

(Core Graveyard :: Plug-ins, defect)

x86_64
Windows 7
defect
Not set
critical

Tracking

(firefox39+ verified, firefox40+ verified, firefox41 verified, firefox-esr3840+ fixed)

VERIFIED FIXED
mozilla41
Tracking Status
firefox39 + verified
firefox40 + verified
firefox41 --- verified
firefox-esr38 40+ fixed

People

(Reporter: yamadat501, Assigned: bugzilla)

References

Details

(Keywords: hang, regression)

Attachments

(1 file, 1 obsolete file)

After 0402 nightly, browser UI shows strange behavior when using Unity Web Player.

Step to Reproduce

1. Open http://zizi.hotcom-web.com/unity/block/block.html
2. Play game (needs several or many clicks on plugin content)

Expected Result:
Anytime, Browser UI works normally.

Actual Result:
Browser UI becomes unresponsive completely(can't change tab, open menu and so on).
By losing focus, browser UI works normally again.

Regression range(In my test):
last OK: 20150331102803
https://hg.mozilla.org/integration/mozilla-inbound/rev/4156586d7ac6
first bad: 20150331103104
https://hg.mozilla.org/integration/mozilla-inbound/rev/829195e67537

Bug 1133351?
[Tracking Requested - why for this release]: UI hang.

I can confirm the problem and regression rang as well.

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4156586d7ac6&tochange=829195e67537
Blocks: 1133351
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(aklotz)
Keywords: hang, regression
I have a simplified STR:

1. Open http://zizi.hotcom-web.com/unity/block/block.html
2. Click somewhere in the plugin (but not a button), hold the mouse down for a few seconds, and then release.

I've done this while observing the local input state of the process. From what I was seeing, the plugin grabs mouse capture via the SetCapture API but doesn't always release it via ReleaseCapture. For whatever reason mouse capture previously still managed to release anyway, but this is no longer the case.

I'm going to open a discussion with the Unity folks to see what we can come up with.
Flags: needinfo?(aklotz)
Tracking for 40 since this is a regression.
Any updates from the unity folks on this?
With Ver. 4.6.5f released a week ago, STR in Comment 2 is no more reproducible, probably.
But by many clicks in the plugin content over a short period of time, UI hang still happens.
(In reply to Johnny Stenback  (:jst, jst@mozilla.com) from comment #4)
> Any updates from the unity folks on this?

I've sent them an email and will update this bug as I hear more.
This is a good demo for STR and QA because it exhibits the problem and the game also uses pointer lock.
https://unity3d.com/showcase/live-demos#3rd-person-shooter
Attached patch Mouse capture quirk fix (obsolete) — Splinter Review
Since there has been concern expressed about compatibility issues with older versions of the Unity plugin, I've added a quirk flag to address this.

1) We hook SetCapture calls for the Unity window.
2) We set a GetMessage hook and watch for WM_MOUSEMOVE and WM_LBUTTONUP to detect when we should release capture.
3) We set a CALLWNDPROC hook to watch for WM_CAPTURECHANGED to know if some external stimulus has caused us to lose capture.
Assignee: nobody → aklotz
Status: NEW → ASSIGNED
Attachment #8608295 - Flags: review?(jmathies)
A couple of minor fixes
Attachment #8608295 - Attachment is obsolete: true
Attachment #8608295 - Flags: review?(jmathies)
Attachment #8608298 - Flags: review?(jmathies)
Attachment #8608298 - Flags: review?(jmathies) → review+
Flags: qe-verify+
Comment on attachment 8608298 [details] [diff] [review]
Mouse capture quirk fix (r2)

Approval Request Comment
[Feature/regressing bug #]: bug 1133351
[User impact if declined]: Users might lose ability to click on Firefox windows after clicking inside the Unity plugin
[Describe test coverage new/current, TreeHerder]: Currently on inbound en route to m-c. Needs manual verification with the Unity plugin installed.
[Risks and why]: Low. It's critical for correct operation of Firefox on Windows when Unity plugin is run. There is a slight chance of unforeseen incompatibilities with certain Unity content but I'm not expecting problems.
[String/UUID change made/needed]: None
Attachment #8608298 - Flags: approval-mozilla-aurora?
I tested inbound build and confirmed the problem was fixed.

Thank you for your works!
https://hg.mozilla.org/mozilla-central/rev/4c25f051aba3
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Comment on attachment 8608298 [details] [diff] [review]
Mouse capture quirk fix (r2)

We care about Unity, taking it.
Attachment #8608298 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment on attachment 8608298 [details] [diff] [review]
Mouse capture quirk fix (r2)

Requesting for beta as well since we're requesting uplift for bug 1133351.

Approval Request Comment
[Feature/regressing bug #]: bug 1133351
[User impact if declined]: Users might lose ability to click on Firefox windows after clicking inside the Unity plugin
[Describe test coverage new/current, TreeHerder]: Currently on inbound en route to m-c. Needs manual verification with the Unity plugin installed.
[Risks and why]: Low. It's critical for correct operation of Firefox on Windows when Unity plugin is run. There is a slight chance of unforeseen incompatibilities with certain Unity content but I'm not expecting problems.
[String/UUID change made/needed]: None
Attachment #8608298 - Flags: approval-mozilla-beta?
Comment on attachment 8608298 [details] [diff] [review]
Mouse capture quirk fix (r2)

Approved for uplift to beta. Looks a bit risky but let's give it a shot. We should verify this fix on beta.
Attachment #8608298 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Belatedly tracking for 39.
I couldn't manage to reproduce this issue with Nightly from 2015-04-08 on Windows 7 64-bit, using Unity 4.6.5f & 5.0.3f2 and the demos from comment 0 and comment 7.
Toshihiro Yamada or Alice, could you please confirm the fix on Firefox 39.0b3 build 2 [1]? Thanks in advance!

[1] http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/39.0b4-candidates/build2/win32/en-US/
Flags: needinfo?(yamadat501)
confirmed, this was fixed on 
https://hg.mozilla.org/releases/mozilla-beta/rev/780e1c2b8013
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0 ID:20150609130336
Many thanks, Alice! Based on comment 12 and comment 21, changing the flags accordingly!
Status: RESOLVED → VERIFIED
Flags: needinfo?(yamadat501)
Alice, could you please also check 40 beta 4 [1]? Many thanks! :)

[1] http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/40.0b4-candidates/build1/
Flags: needinfo?(alice0775)
I cannot reproduce the problem anymore on Firefox40.0b4.

https://hg.mozilla.org/releases/mozilla-beta/rev/664b98d33a1b
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0 ID:20150713153304
Flags: needinfo?(alice0775)
Flags: qe-verify+
Comment on attachment 8608298 [details] [diff] [review]
Mouse capture quirk fix (r2)

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
Needs to land alongside bug 1133351 if those patches are approved for esr38. If not, those patches will cause a regression in the Unity plugin.
User impact if declined:
Unity plugin will not correctly release mouse capture on Windows.
Fix Landed on Version:
Released on 39.
Risk to taking this patch (and alternatives if risky): 
Pretty minimal at this point. These patches have ridden the trains and have been doing well on release.
String or UUID changes made by this patch: None

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.
Attachment #8608298 - Flags: approval-mozilla-esr38?
Comment on attachment 8608298 [details] [diff] [review]
Mouse capture quirk fix (r2)

Taking this as a prereq for bug 1133351. ESR38+
Attachment #8608298 - Flags: approval-mozilla-esr38? → approval-mozilla-esr38+
Alice, would you mind verifying this also in the latest Firefox 38.2 ESR build when you get some time: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/38.2.0esr-candidates/build1/win32/en-US/
Flags: needinfo?(alice0775)
(In reply to Florin Mezei, QA (:FlorinMezei) from comment #30)
> Alice, would you mind verifying this also in the latest Firefox 38.2 ESR
> build when you get some time:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/38.2.0esr-candidates/
> build1/win32/en-US/


I cannot reproduce the hangup with STR comment#0 on ESR38.1 and ESR38.2 both.


I can only verify that Bug 1165189 is fixed on ESR38.2, see Bug 1165189 Comment 24.
Flags: needinfo?(alice0775)
Depends on: 1320019
Depends on: 1320020
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.