DLL name: gemgecko10.dll DLL versions to block: 126.96.36.199 Applications, versions, and platforms affected: Firefox on Windows Homepage and other references and contact info: gemgecko10.dll appears to be part of an addon or rebranding package made by 'Gemius'. Reasons: BExternal.dll appears to be manipulating our preferences off the main thread, causing crashes. See crash reports like https://crash-stats.mozilla.com/report/index/537b69e9-e0fc-4e96-9ded-700e82120105 https://crash-stats.mozilla.com/report/index/28c469e4-e8a2-464d-9cdd-56dd72120105
7 years ago
tracking-firefox10: --- → ?
More info... From: http://stackoverflow.com/questions/4713441/localizing-extension-descriptions-before-gecko-1-9 I got Megapanel PBI / Gemius, which I found on wikipedia: http://translate.google.com/translate?hl=en&sl=pl&u=http://pl.wikipedia.org/wiki/Megapanel_PBI/Gemius Which looks like a sort of census / survey thingy made by these people: http://translate.googleusercontent.com/translate_c?hl=en&prev=/search%3Fq%3DBadanie%2BMegapanel%2BPBI/Gemius%26hl%3Den%26client%3Dsafari%26rls%3Den%26prmd%3Dimvns&rurl=translate.google.com&sl=pl&u=http://pl.wikipedia.org/wiki/Gemius_SA Official site: http://www.gemius.com/ And, uhhhh...they made a persona: https://addons.mozilla.org/en-US/firefox/addon/gemius/ I can't find where to download the XPI though, and maybe it's other external bundleware
Yeah I don't think this is malice. We should contact them and get them to fix their code if possible.
It's strange that it is so high though...do we have a lot of polish beta users? It sounds like there is < 50,000 total users in the "survey group", and not all of them have the add-on installed. I would also expect the correlation reports to shout from the rooftops about the add-on as well.
Christian's findings from comment 2 are mostly correct. Gemius is a web stats company and PBI (Polskie Badania Internetu) is a consortium of the top sites in Poland (Onet, WP, Gazeta, Interia and Rzeczpospolita) made for gathering web page and apps stats. The Megapanel survey (operated by Gemius on behalf of PBI) is regarded as the best representation of how the web in Poland works, whose sites and services are the most popular. Advertising budgets of every web campaign are based on Megapanel findings. Gemius JS files are basically on every important site in Poland. The netPanel app is used to monitor sites that don't include their scripts. The findings from the JS scripts are combined with the extrapolated findings from the app, and published monthly, e.g. here: http://www.internetstandard.pl/news/378779/Wyniki.Megapanel.PBI.Gemius.za.pazdziernik.2011.html The netPanel app is offered to some users through those JS scripts. It's not available for a direct download, since they only offer it through a pop-up window to users that fit their statistical model. Description in Polish: http://panel.pbi.org.pl/jakpodlaczyc.php 50k users is a lot, but taking into account that basically any web page in Poland can offer you their monitoring app, it's not that unbelievable.
Our metrics team have some contact info to those ppl. CC'ing Daniel.
As with bug 715744, before we track for a release we should also make sure to understand * the total add-on population * crashes highly correlated with this DLL
[Triage Comment] I think we're too close to the end of the cycle to prepare and execute on a DLL blocklist addition for FF10. We would, however, consider uplifting the entry once ready for FF11.
tracking-firefox10: ? → -
Was Gemius contacted about this issue?
Alex: similar to bug 715744, this dll is partially causing a topcrash (bug 715757 comment 4).
tracking-firefox10: - → ?
The crash in CrashInJS caused by gemgecko10.dll 188.8.131.52 (58%) is #8 top crasher in 10.0b4.
Bug 715757 comment 7 says that blocking this and BExternal.dll remove 99% of the #8 topcrash.
Zbigniew, Daniel: So I guess nobody contacted Gemius about this bug? If nobody did, I will.
Given the topcrash status of bug 715757, we can still consider blocklisting gemgecko10.dll for FF10. The steps to do this would need to be 1) (DONE) Create a blocklist patch 2) Create a try build, get the patch r+'d 3) QA to test Gemius's software to make sure that the blocklist is successful and there are no functional regressions 4) Land on beta with QA's signoff and all of this would need to happen before beta 6 goes to build on Monday evening PT. I'm sending this over to Kyle to see if he can take care of #2 today. We'd consider blocklisting between beta 6 and our RC if 715757 was a startup crasher, but that doesn't appear to be the case.
Assignee: nobody → khuey
tracking-firefox10: ? → +
Of course #3 is still gated on finding an XPI or Marek's outreach producing an XPI - so this is even less likely to make the cut.
Sending over to Luke since Kyle's out for the day.
Assignee: khuey → luke
Comment on attachment 586292 [details] [diff] [review] Patch Patch itself looks fine, I thought that dll blocklist entries like this just needed r+ from someone on addons/product teams and not "code review"?
Attachment #586292 - Flags: review?(ehsan) → review+
Sent an email to email@example.com with a short description of the situation and a link to this bug.
(In reply to Vladimir Vukicevic (:vlad) from comment #18) > Comment on attachment 586292 [details] [diff] [review] > Patch > > Patch itself looks fine, I thought that dll blocklist entries like this just > needed r+ from someone on addons/product teams and not "code review"? It also requires code review to catch things like bug 715744 comment 11, for example.
Comment on attachment 586292 [details] [diff] [review] Patch I do not know how to make 3 or 4 happen so I'll request approval for beta. [Approval Request Comment] User impact if declined: Top-crash Testing completed (on m-c, etc.): comment 17 Risk to taking this patch (and alternatives if risky): low: it is a DLL blocklist
Attachment #586292 - Flags: approval-mozilla-beta?
(In reply to Marek Stępień [:marcoos] from comment #19) > Sent an email to firstname.lastname@example.org with a short description of the situation > and a link to this bug. Thanks Marek. It would be very helpful to have access to the Gemius software in order to test the try build from comment#17 (thanks Luke). We'll test the blocklist entry with Gemius's software before approving for Beta 10.
We weren't in a position to take this blocklist entry for beta 6. We should consider doing this instead for FF11.
tracking-firefox11: --- → +
Attachment #586292 - Flags: approval-mozilla-beta? → approval-mozilla-beta-
I contacted a person from Gemius (Marcin Mazurkiewicz) who is sending us weekly stats reports.
I got a response from Marcin. He said that he got in touch with the team working on the code and he asked us to give them a day or two to analyze the data before we commit this patch. Is there someone from our team I should suggest as a point of contact for Gemius ppl working on this in case they have questions or should I suggest them to use this bug for any upcoming communication?
Got a reply from Gemius. Translation of the important parts: "We decided to temporarily update the addon to a version that does not contain gemgecko10.dll and marked it as incompatible with Fx 10 (gemgecko10.dll is only used when the addon is installed in Fx10)". "We will withdraw from releasing versions of the addon containing gemgecko10.dll until the problem is fixed and the addon made available to Aviary.pl [the Polish Mozilla l10n team - marcoos] for verification." I will ask them to make it available to some of the people from this bug, not neccessarily the L10n team. :)
Replied to them and asked them to make the add-on available for testing. If they don't feel like releasing it publically, I've asked them to e-mail it to Alex.
Given that I don't think the blocklist is necessary. Please reopen if you disagree.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
Awesome! Thanks Marek for driving this. It would be awesome if they could share their findings on why gemgecko regressed in Fx 10, but overall, glad to see their approach :)
It regressed because we added an assert that says "hey that thing you've been doing for years, that's a bad thing to do".
To be clear: "hey that *bad* thing you've been doing for years, ..."
Hello guys, I'm an employee of Gemius company and developer of NetPanel project, where we use XPCOM component (gemgeckoX.dll) to communicate with Firefox browser. First of all, thanks for the report. gemgeckoX.dll is an old pice of code, created years ago for gecko 1.8 based FF. Recently it was made compatible with browsers based on gecko 2.0 (and higher) - we wrapped it in .xpi package and applied changes from https://developer.mozilla.org/en/XPCOM/XPCOM_changes_in_Gecko_2.0 article. From then, we updated the .xpi package every FF release recompling the component (so 10 in gemgecko10.dll file name means that it was compiled with gecko sdk 10). We never got any crushes during tests, nor bug reports from users. I have dug the component's source code - the crash is probably caused by calling nsIPrefBranch off the component's main thread (as described in bug 715757). We will fix it in next update :) BTW: is there any doc about XPCOM thread safety? Marek Stępień asked for the extension for tests. Is the request is still valid?
We've now heard from a couple of employees at Gemius that their latest version will be rolled out soon. Removing the tracking flags for specific releases.
tracking-firefox10: + → -
tracking-firefox11: + → -
Whiteboard: [dll] → [dll][3rd-party-bustage]
You need to log in before you can comment on or make changes to this bug.