Closed Bug 436302 Opened 16 years ago Closed 15 years ago

Blocklist Roboform plugin versions prior to 6.9.89

Categories

(Toolkit :: Blocklist Policy Requests, defect)

Product:
Toolkit
Component:
Blocklist Policy Requests
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: MatsPalmgren_bugz, Assigned: morgamic)

Details

(Keywords: crash) 

"Top Crashers for Firefox 3.0" lists strchr() at #19 on Windows,
with 1295 crashes in the past two week period.
The vast majority of those crashes appears to be caused by
the Roboform plugin.

Example crash reports:
bp-a13d3c78-2c91-11dd-870b-0013211cbf8a
bp-24beb36b-2c21-11dd-bef6-0013211cbf8a
bp-66621594-2a8e-11dd-9907-001321b13766
bp-57c098a3-2bff-11dd-94fc-001cc4e2bf68
bp-5efa711e-2c2f-11dd-b06c-001321b13766

Stack:
mozcrt19.dll	strchr	 strchr.asm:101
rfmozhlp.dll	rfmozhlp.dll@0x3d6f	
rfmozhlp.dll	rfmozhlp.dll@0x14b4	
roboform.dll	roboform.dll@0x1a7448	
roboform.dll	roboform.dll@0x1a6f51	
roboform.dll	roboform.dll@0x1a6b8b	
user32.dll	user32.dll@0x21922	
user32.dll	user32.dll@0x1b316	
user32.dll	user32.dll@0x178cf	
ntdll.dll	ntdll.dll@0xe452	
user32.dll	user32.dll@0x9401	
xul.dll	nsAppShell::ProcessNextNativeEvent	mozilla/widget/src/windows/nsAppShell.cpp:142
winmm.dll	winmm.dll@0x4e7a	


I think this is known issue by the vendor that has been fixed
in version 6.9.89
http://www.roboform.com/news.html

We should consider blacklisting the versions that crashes.
yes, we submitted this update to mozilla and 2 weeks later still nothing.

ver 6.9.89 has no problems with FF 3.0 RC1
Which versions crash and on which versions of Firefox?
rfmozhlp.dll which is a part of our addon up to ver 6.9.88 crashes FF 3.0 RC1 but not FF 2.0 or FF 1.5.

starting with RF addon ver 6.9.89 nothing crashes.

ver 6.9.89 has been submitted to Firefox Addons site more than a week ago.
I've gone in, reviewed it and approved Roboform v6.9.89 on AMO and it's public. It should appear shortly @ https://addons.mozilla.org/en-US/firefox/addon/750
so despite of the now updated plugin, will prior versions get blocked or not?
Doesn't look like the uptake on the new roboform version is going as quick as we might hope.   This crash appears to be ranked #31 since the release of fx3. with around 655 crashes in the last 36 hours.

http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&range_unit=days&version=Firefox%3A3.0&signature=strchr&range_value=2

quick sample shows these version of the .dll is loaded
roboform.dll  	6.9.84.0
roboform.dll  	6.9.5.0
rfmozhlp.dll  	6.9.88.0



should we go ahead and block?
we are pushing updates, but it takes time to update everybody.

ver 6.9.89 is OK.

versions before 6.9.89 crash FF 3.0 in rfmozhlp.dll (this entire dll is removed in 6.9.89).


Dave -- is there a way to do a more complex version pattern (boolean NOT)?
Assignee: nobody → morgamic
Or, we could just disable all plugins that have rfmozhlp.dll -- would that work?
rfmozhlp.dll is teh culprit here and it has been removed starting with ver 6.9.89.

try to block it and see what happens.

old RF may not work, as it needs to know Moz version to connect the right DLL.
Can I just confirm, is roboform an extension(In reply to comment #9)
> Or, we could just disable all plugins that have rfmozhlp.dll -- would that
> work?

Just to check, it looks like roboform is an extension and so we must use the extension part of the blocklist which cannot block individual libraries. Something like:

    <emItem id="{22119944-ED35-4ab1-910B-E619EA06A115}">
      <versionRange minVersion="0" maxVersion="6.9.89">
        <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
          <versionRange minVersion="3.0" maxVersion="*"/>
        </targetApplication>
      </versionRange>
    </emItem>

should do the job I think.

does not seem to be correct, unless you use different max definition.

6.9.89 does work ok.

the max version that crashes is 6.9.88.
Yep sorry, that's what I get for hand writing XML before my morning cuppa
The related crash is caused completely by RoboForm application 6-9-88
and early.
It is not RoboForm Toolbar extension issue.

Detialed description:
roboform.exe tries to detect Firefox version.
It loads rfmozhlp.dll via Windows hooks mechanism.
This small library (rfmozhlp) is build on Gecko SDK 1.7.13.
It performs several calls to Preferences Service.

So rfmozhlp working from inside firefox.exe process.
Rfmozhlp is not a plugin or extension.

Problem can be solved by 2 ways:
1. Using interception of KERNEL32.DLL!LoadLibrary.
Interceptor should prevent rfmozhlp.dll from loading.
2. Explore call stack of NS_GetFrozenFunctions.
rfmozhlp.dll calls NS_GetFrozenFunctions during XPCOMGlue initialization.
If call stack contain call from rfmozhlp.dll, then NS_GetFrozenFunctions should return NS_FAILED value.
(In reply to comment #14)
> The related crash is caused completely by RoboForm application 6-9-88
> and early.
> It is not RoboForm Toolbar extension issue.
> 
> Detialed description:
> roboform.exe tries to detect Firefox version.
> It loads rfmozhlp.dll via Windows hooks mechanism.
> This small library (rfmozhlp) is build on Gecko SDK 1.7.13.
> It performs several calls to Preferences Service.

If that happens regardless of whether the roboform toolbar is installed or not then there is no way we can tackle this with the blocklist.

in latest 3.0.1 crash data I'm looking at it this appears to be the #11 top crash now.  Any thoughts on next steps.  I wonder why we see this going up the top crash list not down if roboform updates are continuing to be pushed.

maybe there are other binary components that are causing the same signature.  going to have to dig deeper to figure that out...
we have about 50% of users upgraded to ver 6.9.90.

but still there is a number of users sitting on old versions.

we will investigate whether some sites are still pushing old versions,
as we certainly do not do it ourselves.
in http://forums.mozillazine.org/viewtopic.php?f=23&t=848295 a user mentioned a crash [@ rfproxy_27.dll@0x225fd] when upgrading from Fx 3.0.1 to 3.0.2 (beta/build5).

bp-74469270-8038-11dd-8fb3-0013211cbf8a
rfproxy_27.dll 	6.9.90.0
roboform.dll 	6.9.90.0

of course, verification is needed, but it seems we get a problem with 3.0.2 + .90.0 like with 3.0.0/.1 with <.89.0
unsure if it's worth filing a new bugreport ...
it is definitely not this crash.

as this crash is in rfmozhlp.dll of old versions and
there is no new versions of this dll, it was completely removed in 6.9.90

if you have any significant bugs to report, please open another ticket here
or at http://support.roboform.com
Vadim: the crash referred to in comment 18 is bug 455283. A RoboForm developer claims that it's a crash on startup. Can you check to see if that's the same crash or a different one?
Assuming we're not firm on whether or not to block?  Let please let me know if that's not the case.
Summary: Blacklist Roboform plugin versions prior to 6.9.89 → Blocklist Roboform plugin versions prior to 6.9.89
if you want to block and provide clear path to update, this might be ok.

we assume taht all active RF users should have upgraded already.
(In reply to comment #22)
> if you want to block and provide clear path to update, this might be ok.
> 
> we assume taht all active RF users should have upgraded already.

If all active users have updated hen blocklisting would have no real effect. In either case locklisting doesn't stop users of old versions updating to newer un-blocked versions.
Windows XP64 SP2 / Roboform 6.9.94 (This comment is FYI.)

When attempting to install the Roboform Plugin the following error occurs:

"AI Roboform Toolbar for Firefox" could not be installed because it is not compatible with your Minefield build type (WINNT_x86_64-msvc). Please contact the author of this item about the problem.

Minefield does not crash and continues to function normally. I assume this will be fixed eventually, either by Siber Systems and/or Mozilla.
richard: to my knowledge, mozilla.org does not provide 64bit versions of Mozilla which means you're using a build from someone else. The error message is correct and is unlikely to change until mozilla.org provides official 64bit builds.

note that your experience is unrelated to this bug.
there is no RoboForm 64-bit in ver 6, and
there is no Adapter for Mozilla for it.

so you can only use it in 32-bit compatibility mode in 32-bit browsers.

we will implement 64-bit ver in RF ver 7.
Reopen if this is still a priority.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
is there any reason why RoboForm Adapter ver 6.9.95 is still not approved on Firefox addons.

it was submitted on June 20.

tody is July 17th -- one month later.

this version contain that Frozen Adapter that was talked so much about here.
Vadim, as it seems .95 is now available officially on AMO.
Furthermore there seems to be movement concerning establishing a more automatic reviewing process. see the relevant posts at http://blog.mozilla.com/addons/ .
that's a goiod movement.

but it does not solve the immediate problem
of not making public the new RF Adapter for 1 month.
Product: addons.mozilla.org → Toolkit
You need to log in before you can comment on or make changes to this bug.