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)
Tracking
(firefox39+ verified, firefox40+ verified, firefox41 verified, firefox-esr3840+ fixed)
VERIFIED
FIXED
mozilla41
People
(Reporter: yamadat501, Assigned: bugzilla)
References
Details
(Keywords: hang, regression)
Attachments
(1 file, 1 obsolete file)
14.27 KB,
patch
|
jimm
:
review+
Sylvestre
:
approval-mozilla-aurora+
lizzard
:
approval-mozilla-beta+
lmandel
:
approval-mozilla-esr38+
|
Details | Diff | Splinter Review |
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?
Comment 1•9 years ago
|
||
[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
status-firefox39:
--- → unaffected
status-firefox40:
--- → affected
tracking-firefox40:
--- → ?
Ever confirmed: true
Flags: needinfo?(aklotz)
Keywords: hang,
regression
Assignee | ||
Comment 2•9 years ago
|
||
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)
Comment 4•9 years ago
|
||
Any updates from the unity folks on this?
Reporter | ||
Comment 5•9 years ago
|
||
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.
Assignee | ||
Comment 6•9 years ago
|
||
(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.
Assignee | ||
Comment 7•9 years ago
|
||
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
Assignee | ||
Comment 8•9 years ago
|
||
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 | ||
Comment 9•9 years ago
|
||
A couple of minor fixes
Attachment #8608295 -
Attachment is obsolete: true
Attachment #8608295 -
Flags: review?(jmathies)
Attachment #8608298 -
Flags: review?(jmathies)
Updated•9 years ago
|
Attachment #8608298 -
Flags: review?(jmathies) → review+
Assignee | ||
Updated•9 years ago
|
Flags: qe-verify+
Assignee | ||
Comment 11•9 years ago
|
||
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?
Reporter | ||
Comment 12•9 years ago
|
||
I tested inbound build and confirmed the problem was fixed. Thank you for your works!
Comment 13•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/4c25f051aba3
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox41:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Comment 14•9 years ago
|
||
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+
Assignee | ||
Comment 15•9 years ago
|
||
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?
Assignee | ||
Comment 16•9 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/62ad4980571e
Comment 17•9 years ago
|
||
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+
Updated•9 years ago
|
Comment 18•9 years ago
|
||
https://hg.mozilla.org/releases/mozilla-beta/rev/a75365b95a17
tracking-firefox39:
--- → ?
Comment 20•9 years ago
|
||
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)
Comment 21•9 years ago
|
||
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
Comment 22•9 years ago
|
||
Many thanks, Alice! Based on comment 12 and comment 21, changing the flags accordingly!
Status: RESOLVED → VERIFIED
Flags: needinfo?(yamadat501)
Comment 25•9 years ago
|
||
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)
Comment 26•9 years ago
|
||
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)
Updated•9 years ago
|
Flags: qe-verify+
Assignee | ||
Comment 27•9 years ago
|
||
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 28•9 years ago
|
||
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+
Updated•9 years ago
|
status-firefox-esr38:
--- → affected
tracking-firefox-esr38:
--- → 40+
Comment 30•9 years ago
|
||
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)
Comment 31•9 years ago
|
||
(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)
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•