Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4 (Vista + SP 1 installed) Steps to reproduce: -> Go to the Google Pack Site and install the Google Pack -> Restart Firefox after the Google Pack is installed -> Go now again to the Google Pack Site -> Firefox crash immediately when go to the Google Pack Site http://crash-stats.mozilla.com/report/index/48e3168a-f695-11dc-aa9a-001a4bd43e5c According to IRC this might be a Problem with the Google Plugin (thanks Gavin): "that goes through npCIDetect11, which is a google updater component "google updater plugin", apparently" This crash does not happen with Trunk but i think this is more since its "Minefield" and not "Firefox".
Can we get the right people at Google cc'd on this bug?
fair to call this a dupe of 422018? Google has been made aware of the issue and we're trying to get their Firefox team engaged.
(In reply to comment #2) > fair to call this a dupe of 422018? > > Google has been made aware of the issue and we're trying to get their Firefox > team engaged. > Hey Kev, i don't think its a dupe of Bug 422018. The Crash Signatur looks different then there. The Crazy thing is that i can surf normal with the Build + Google Pack but every time i go to the Google Pack Site i crash within seconds. A normal Build without Google Pack does not crash on the same site. So i think its this update plugin that cause a Crash when surfing to the Google Pack Site.
FYI. When hitting this bug on Windows Vista, Firefox is shut down by Data Execution Protection. Hopefully that provides guidance as to the nature of the bug.
-'ing this as this appears to be an issue with the google pack. Kev, have we managed to get ahold of someone at google so they are aware of this issue?
Flags: blocking1.9? → blocking1.9-
I've made PSO aware of the problem here as well as with 422018, and we've offered up assistance to the Firefox team through mfinkle. I'm sitting with them on Thursday, and will also ask for an escalation, as I do not believe we've heard anything back.
This bug exists in beta 5 as well - just downloaded and installed.
Still a minus until someone determines that it's not an issue with the google pack. Kev, how did the meeting go? (comment #6).
Flags: blocking1.9? → blocking1.9-
(In reply to comment #9) My question is, if it's a problem with Google Pack, why doesn't it have the same problem with Firefox 2.0.x or even earlier versions of this the beta (or IE or Opera or even Safari, for that matter)? Why isn't it breaking in any other standard compliant browser (even if you discount IE)? To me it sure looks like a Firefox problem, and I don't see how it can be released with that serious an error going on. > Still a minus until someone determines that it's not an issue with the google > pack. > > Kev, how did the meeting go? (comment #6). >
if this started when we switched allocators it's probably because they aren't correctly using NPN_Malloc/NPN_Free. And the reason it wouldn't crash other browsers is that most other browsers don't use distinct allocators for things, however the API for this is crystal clear, any plugin that does not use NPN_Free for data created by the browser for a plugin, or which does not use NPN_Alloc for data it gives to the browser is broken. Signature @0x26dd378 UUID 48e3168a-f695-11dc-aa9a-001a4bd43e5c Time 2008-03-20 08:48:57-07:00 Uptime 965 Product Firefox Version 3.0b4 Build ID 2008030714 OS Windows NT OS Version 6.0.6001 Service Pack 1 CPU x86 CPU Info GenuineIntel family 6 model 15 stepping 8 Crash Reason EXCEPTION_ACCESS_VIOLATION Crash Address 0x26dd378 Comments Crashed while going to Google Pack Website Crashing Thread Frame Signature Source 0 @0x26dd378 1 user32.dll@0x11911 2 user32.dll@0x20816 3 user32.dll@0x139f6 4 ntdll.dll@0x599cd 5 user32.dll@0x13cc2 6 user32.dll@0x13d99 7 ci.dll@0x10ad3 8 ci.dll@0x76c30 9 ci.dll@0x76b08 10 ci.dll@0x9af2 11 ci.dll@0x23e5 12 ci.dll@0x36ed 13 ole32.dll@0x2750e 14 ole32.dll@0x2705a 15 ole32.dll@0x2772c 16 ole32.dll@0x2764e 17 ole32.dll@0x27608 18 ole32.dll@0x275b9 19 ole32.dll@0x276ae 20 ole32.dll@0x2705a 21 ole32.dll@0x27120 22 ole32.dll@0x2705a 23 ole32.dll@0x272c4 24 ole32.dll@0x4e2a1 25 ole32.dll@0x4e202 26 ole32.dll@0x4e1bb 27 npCIDetect11.dll@0x36bb 28 npCIDetect11.dll@0x356e 29 _createobject mozilla/modules/plugin/base/src/ns4xPlugin.cpp:1584 30 npCIDetect11.dll@0x1642 31 ns4xPluginInstance::GetValueInternal(NPPVariable, void*) mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp:1336 32 ns4xPluginInstance::GetJSObject(JSContext*) mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp:1483 33 nsHTMLPluginObjElementSH::GetPluginJSObject(JSContext*, JSObject*, nsIPluginInstance*, JSObject**, JSObject**) mozilla/dom/src/base/nsDOMClassInfo.cpp:9202 34 nsHTMLPluginObjElementSH::PostCreate(nsIXPConnectWrappedNative*, JSContext*, JSObject*) mozilla/dom/src/base/nsDOMClassInfo.cpp:8804 35 nsObjectFrame::NotifyContentObjectWrapper() mozilla/layout/generic/nsObjectFrame.cpp:1789 36 nsObjectFrame::TryNotifyContentObjectWrapper() mozilla/layout/generic/nsObjectFrame.cpp:1597 37 nsObjectFrame::Instantiate(char const*, nsIURI*) mozilla/layout/generic/nsObjectFrame.cpp:1580 38 nsObjectLoadingContent::Instantiate(nsIObjectFrame*, nsACString_internal const&, nsIURI*) mozilla/content/base/src/nsObjectLoadingContent.cpp:1635
There's no evidence that there's a problem in Firefox 2 to fix. (In reply to comment #10) > My question is, if it's a problem with Google Pack, why doesn't it have the > same problem with Firefox 2.0.x or even earlier versions of this the beta (or > IE or Opera or even Safari, for that matter)? Because we've changed they way extensions work throughout the Firefox 3 release cycle.
(In reply to comment #12) > There's no evidence that there's a problem in Firefox 2 to fix. I never said there was. I said the problem does NOT exist in 2.0.x. > (In reply to comment #10) > > My question is, if it's a problem with Google Pack, why doesn't it have the > > same problem with Firefox 2.0.x or even earlier versions of this the beta (or > > IE or Opera or even Safari, for that matter)? > > Because we've changed they way extensions work throughout the Firefox 3 release > cycle. And if that change is making Google Pack - which is pretty popular, especially with the users of Firefox - crash, Mozilla should just go ahead and release Firefox 3 leaving this problem dangling? Whether this is an evangelizing problem, some that Google has to adapt to, or whatever, it better be fixed before the actual release, because it's crashes like these that will make people leave the browser.
PS... just wanted to say it seems to have started working again - in Minefield 3.0 Pre (user string below), if only partially. It is at the very basic page of the pack, not selecting out the software that you already have. Nonetheless, it's still better than a flat out crash. My user string: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008050105 Minefield/3.0pre
this website makes firefox 3 Release Candidate 1 crash the website is:pack.google.com/
Summary: Google Pack Crash Firefox 3 Beta 4 on the Google Pack Site @0x26dd378 → Google Pack Crash Firefox 3 Beta 4 on the Google Pack Site [@ 0x26dd378]
Whiteboard: [google update]
Component: Plug-ins → Other
Product: Core → Plugins
QA Contact: plugins → other
Version: Trunk → unspecified
Crash Signature: [@ 0x26dd378]
Closing old bugs in the Plugins component. We aren't going to track issues in 3rd-party plugins in the Mozilla bug tracker. In addition, support for NPAPI plugins will be removed at the end of this year; for more details see the post at https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/ If there is a serious bug in Firefox, it needs to be filed in the "Core" product, "Plug-Ins" component.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.