User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:19.0) Gecko/19.0 Firefox/19.0 Build ID: 20121025030620 Steps to reproduce: I went to youtube, and opened a video in full screen. Actual results: The Nightly Plugin Container crashed. To get it working, I had to let it crash and refresh the page. Fullscreen then worked. Each video I go to has same process of initial crash when entering fullscreen, but then fullscreen works fine after refreshing the page post crash. Expected results: Video should have gone fullscreen without crash.
forgot to mention, I am running Nightly's 64 bit build.
Can you provide the crash ID from about:crashes? Does it happen in Safe Mode (see https://support.mozilla.org/kb/troubleshoot-firefox-issues-using-safe-mode)? Does it happen with a new profile (see https://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-profiles)? Does it happen with 32-bit Nightly?
Where can I find about:crashes? The problem still occurs in safe mode The problem still occurs in new profiles The problem does NOT occur in 32 bit Nightly
(In reply to jfn4th from comment #3) > Where can I find about:crashes? Type about:crashes in the location bar. I can reproduce in 64-bit builds: https://crash-analysis.mozilla.com/hang-reports/2012/10-26/hr-20121026-e073f611-8b75-4e2a-84e2-ddc1bca9a73d.html
Severity: normal → critical
Status: UNCONFIRMED → NEW
Crash Signature: [@ hang | NtUserSetWindowPos | F799232668______________________________]
Component: Untriaged → Flash (Adobe)
Ever confirmed: true
Keywords: hang, reproducible
Product: Firefox → Plugins
Summary: Nightly Plugin Container crashing. → 64-bit Flash hang in F799232668 when in full screen
Version: 19 Branch → 11.x
I'm pretty sure we don't hook windowprocs in 64-bit builds, so there are going to be plenty of things broken and I don't think we're going to fix them. I don't know why we bother to ship them.
Component: Flash (Adobe) → Plug-ins
Priority: -- → P4
Product: Plugins → Core
Version: 11.x → Trunk
Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/d400b4e402f3 Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121024124702 hang: http://hg.mozilla.org/integration/mozilla-inbound/rev/b6089a8b78d3 Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121024130901 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d400b4e402f3&tochange=b6089a8b78d3 Regressed by: b6089a8b78d3 Neil Deakin — Bug 782547, allow killfocus and deactivate messages to arrive in any order, remove blur suppression code, r=jmathies
I can confirm the same, hanging out... Benjamin, are you telling us to use rather 32 than 64 bit versions??
Yes. The 64-bit versions are experimental and are not supported.
(In reply to Benjamin Smedberg [:bsmedberg] from comment #9) > Yes. The 64-bit versions are experimental and are not supported. @Mr. Smedberg Is this comment also addressed to the rather long-standing group of beta-testers? Or asked in another way: What is your vision for the 64-bit version?
64-bit builds are only for Nightly-testers as there is no 64-bit Beta version. Joe, you should read: https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.planning/aeTXSZ_WFAs
(In reply to Scoobidiver from comment #11) > 64-bit builds are only for Nightly-testers as there is no 64-bit Beta > version. > > Joe, you should read: > https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.planning/ > aeTXSZ_WFAs Thank you Scoobdiver. I've read it, but I have to confess I didn't see it as being conclusive in any way, shape or form. I saw eight comments from various devs made in Nov 2011. It's now almost a year later, and I'd be quite surprised if anyone were to say that in the time that's passed since those posts were made, 64-bit computing has proven to be a dead end and is on its way out. Or have I missed something? And by the way, I apologize for being off the track of what this bug is about. I certainly didn't start the general discussion here about 64-but computing and hope I'm still within the acceptable range of commenting on already-existing comments.
(In reply to Joe Greenman from comment #12) > And by the way, I apologize for being off the track of what this bug is > about. I certainly didn't start the general discussion here about 64-but > computing and hope I'm still within the acceptable range of commenting on > already-existing comments. In the paragraph above, I meant, of course, "64-bit computing".
FYI... Win 64bit builds ARE SUPPORTED. Of course as Tier2 builds. >Breakage or regressions in these platforms does not immediately close the tree; >Developers who break these platforms are expected >to work with platform maintainers to fix problems, >and may be required to back out if a fix cannot be found
I've pushed a backout of bug 782547 to m-c. It should be in the next nightly. https://hg.mozilla.org/mozilla-central/rev/3621795c03e1
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
(In reply to Ryan VanderMeulen from comment #15) > I've pushed a backout of bug 782547 to m-c. It should be in the next nightly. > https://hg.mozilla.org/mozilla-central/rev/3621795c03e1 Thank you very much!
You need to log in before you can comment on or make changes to this bug.