Last Comment Bug 699134 - Extension block request: Roboform
: Extension block request: Roboform
Status: VERIFIED FIXED
[qa!][Read comment #123 before postin...
: verified-aurora, verified-beta
Product: Toolkit
Classification: Components
Component: Blocklisting (show other bugs)
: unspecified
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 691271 703131
Blocks: 701537
  Show dependency treegraph
 
Reported: 2011-11-02 10:33 PDT by Alex Keybl [:akeybl]
Modified: 2016-03-07 15:30 PST (History)
33 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed
fixed
fixed
fixed


Attachments
Screenshot of Browser Integration piece (28.37 KB, image/png)
2011-11-14 14:36 PST, Marcia Knous [:marcia - use ni]
no flags Details
roboform dll block for toolkit/xre/nsWindowsDllBlocklist.cpp (845 bytes, patch)
2011-11-14 16:21 PST, Kev Needham [:kev]
bugzilla: review+
Details | Diff | Splinter Review
Patch for Fx8 ?? (834 bytes, patch)
2011-11-14 17:51 PST, Nick Thomas [:nthomas]
no flags Details | Diff | Splinter Review
changed the version to 7.6.1.0 (835 bytes, patch)
2011-11-14 19:53 PST, Alex Keybl [:akeybl]
jonas: review+
akeybl: approval‑mozilla‑release+
Details | Diff | Splinter Review
roboform.dll 7.6.2.0 (200.28 KB, image/png)
2011-11-15 16:31 PST, Kev Needham [:kev]
no flags Details
FF7.0.1+RF7.6.2 loaded DLLs (34.53 KB, text/plain)
2011-11-15 16:44 PST, Alex Keybl [:akeybl]
no flags Details
FF8.0+RF7.6.2 loaded DLLs (34.45 KB, text/plain)
2011-11-15 16:45 PST, Alex Keybl [:akeybl]
no flags Details
FF8.0.1+RF7.6.2 loaded DLLs (34.21 KB, text/plain)
2011-11-15 16:46 PST, Alex Keybl [:akeybl]
no flags Details
Fx7.0.1+Roboform7.6.2 on XP (9.36 KB, text/plain)
2011-11-15 17:15 PST, juan becerra [:juanb]
no flags Details
Fx8.0+Roboform7.6.2 on XP (9.59 KB, text/plain)
2011-11-15 17:16 PST, juan becerra [:juanb]
no flags Details
Fx8.0.1+Roboform7.6.2 on XP (9.01 KB, text/plain)
2011-11-15 17:22 PST, juan becerra [:juanb]
no flags Details
List of dlls loaded in scenarios listed in testing matrix using Fx8+699134 try-server build. (14.35 KB, application/zip)
2011-11-16 14:23 PST, juan becerra [:juanb]
no flags Details
Don't attempt to block DLLs loaded as data files (1.67 KB, patch)
2011-11-16 14:50 PST, :Ehsan Akhgari
benjamin: review+
Details | Diff | Splinter Review
dlls loaded in scenarios on Win7, using trybuild in comment #85, (19.16 KB, application/zip)
2011-11-17 00:09 PST, juan becerra [:juanb]
no flags Details
dlls loaded in scenarios on XP, using trybuilds in comment #85 (17.37 KB, application/zip)
2011-11-17 00:11 PST, juan becerra [:juanb]
no flags Details
Protect against reentrancy (2.92 KB, patch)
2011-11-17 18:34 PST, :Ehsan Akhgari
benjamin: review-
Details | Diff | Splinter Review
Revised sentinel (4.27 KB, patch)
2011-11-18 06:14 PST, Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg]
benjamin: review-
Details | Diff | Splinter Review
Final version with sentinel (4.56 KB, patch)
2011-11-18 18:26 PST, Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg]
benjamin: approval‑mozilla‑aurora+
benjamin: approval‑mozilla‑beta+
benjamin: approval‑mozilla‑release+
Details | Diff | Splinter Review
blocklist.xml as requested by Jorge Villalobos in #132 (11.82 KB, text/plain)
2011-11-21 04:01 PST, PAdam
no flags Details

Description Alex Keybl [:akeybl] 2011-11-02 10:33:34 PDT
Extension name: Roboform
Extension UUID: ?
Extension versions to block: <7.6.2
Applications, versions, and platforms affected affected: FF8 and up, Windows tested, but likely affects all platforms
Block severity: hard, given the 

Homepage, AMO listing, other references and contact info: 
http://www.roboform.com/platforms/browsers/firefox
Vadim Maslov (vm@roboform.com)

Reasons:
Crashing on startup with default extension prefs. See bug 691271.
Comment 1 Robert Kaiser 2011-11-02 16:47:32 PDT
(In reply to Alex Keybl [:akeybl] from comment #0)
> Extension UUID: ?

{22119944-ED35-4ab1-910B-E619EA06A115} for Roboform Toolbar for Firefox, https://addons.mozilla.org/addon/750

Though it looks like this also happens for a lot of people who don't have the toolbar installed but Roboform is hooking their DLLs into Firefox, so we actually might need a DLL blocklist, which IIRC needs to be done in code. The DLLs names are rf-firefox.dll and roboform.dll, the version range fits for those.
Comment 2 Marcia Knous [:marcia - use ni] 2011-11-13 15:24:46 PST
I tested this again today in a VM and I was easily able to reproduce the crash using Roboform 7.5.2. If the Firefox process is attached to Roboform you get a startup crash until you go into the options an unattached the Roboform process.

The most recent version on their site is 7.6.3. I need to check to make sure that version is not causing any crashes. This will be tedious unless we do a backend query on Socorro.

I assume for a dll block we would need something like the following for each version of Roboform below 7.6.3:

rf-firefox.dll 	7.5.2.0 	7EA6667FE7B948C2B40E2849103E39612 	rf-firefox.pdb
roboform.dll 	7.5.2.0 	73136D6790324670BFFF2E8BE79B248E2 	RoboForm.pdb

For volume, the three signatures in Bug 691271 account for over 18K in crashes across all Firefox versions in the last week.
Comment 3 Marcia Knous [:marcia - use ni] 2011-11-13 15:28:41 PST
http://www.oldapps.com/roboform.php is a good resource for listing all of the old versions.
Comment 4 [:Cww] 2011-11-13 17:13:25 PST
Marcia, if you have the roboform crash, can you start in safe mode?
Comment 5 Marcia Knous [:marcia - use ni] 2011-11-14 10:55:25 PST
Yes, in my VM testing it crashes even if you start in safe mode. You get the safe mode dialog, but right after that you crash.

(In reply to [:Cww] from comment #4)
> Marcia, if you have the roboform crash, can you start in safe mode?
Comment 6 Kev Needham [:kev] 2011-11-14 12:54:59 PST
Just for clarification, is this only an issue with Firefox 8? e.g. will we be blocking all versions through 7.5.2.0 for Firefox 8.0 only?
Comment 7 Marcia Knous [:marcia - use ni] 2011-11-14 13:48:18 PST
The lion's share of crashes seem to affect Firefox 8, this is looking at volume over the last week for the three signatures:

DbgBreakPoint - 11263 crashes in Firefox 8, 30 in 7.0.1
DebugBreak - 5118 crashes in Firefox 8, 37 in 7.0.1
kernelbase.dll@0x31f66 - 592 in Firefox 8, 2 in 7.0.1

But these crashes do affect versions up to 10 from what I can see.
Comment 8 Kev Needham [:kev] 2011-11-14 13:52:32 PST
Ok, could you see if you can replicate the crash with the extension blocked?

We can ask Wil to stage a block, but if you can test with the following entry added to the profile blocklist.xml, that'd be a good start to determine if we do need to block the DLL as well. I'd like to check that first, as we'll need to block it in the app (or ask roboform to respin and include a version string in the dll description, as the file version can't be checked iirc)

BL entry would look something akin to the following, assuming we're hard blocking anything before 7.6.3 for Firefox 8 and up:

<emItem id="{22119944-ED35-4ab1-910B-E619EA06A115}">
  <versionRange minVersion="0.1" maxVersion="7.6.2">
	<targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
	  <versionRange minVersion="8.0a1" maxVersion="*"/>
	</targetApplication>
  </versionRange>
</emItem>
Comment 9 Marcia Knous [:marcia - use ni] 2011-11-14 14:23:18 PST
Bug 702321 has the information about the latest version as well as the top versions implicated in the crash.
Comment 10 Marcia Knous [:marcia - use ni] 2011-11-14 14:36:15 PST
Created attachment 574428 [details]
Screenshot of Browser Integration piece

I created the xml file in Comment 8 and added it to my profile.

If both boxes are checked in the attached screenshot, Firefox still crashes on startup.

The only way I can get Firefox to start is if I uncheck the second box "Attach Roboform to Firefox...". I am testing with version 7.5.2.0 of Roboform in a Win XP VM.
Comment 11 juan becerra [:juanb] 2011-11-14 15:11:31 PST
I see the same thing as Marcia: adding the entry in comment #8 to the blocklist.xml does nothing to prevent the crash in Fx8 with version 7.5.2 of the addon, whether I add the entry in the existing file in the installation directory or adding a blocklist.xml in the user's profile folder.
Comment 12 Dave Townsend [:mossop] 2011-11-14 15:54:03 PST
(In reply to juan becerra [:juanb] from comment #11)
> I see the same thing as Marcia: adding the entry in comment #8 to the
> blocklist.xml does nothing to prevent the crash in Fx8 with version 7.5.2 of
> the addon, whether I add the entry in the existing file in the installation
> directory or adding a blocklist.xml in the user's profile folder.

Exactly what method are you using to test this? Just editing the blocklist.xml file in the profile won't actually have any effect unless you also do something like deleting extensions.ini and extensions.sqlite at the same time.
Comment 13 Kev Needham [:kev] 2011-11-14 16:21:08 PST
Created attachment 574474 [details] [diff] [review]
roboform dll block for toolkit/xre/nsWindowsDllBlocklist.cpp

If a DLL block is required, here's the patch that needs to be applied and tested to toolkit/xre/nsWindowsDllBlocklist.cpp (apologies, I've been waiting for my repo to update, so can't submit a try build yet, and I have to leave for a couple hours). Per comment #12, please re-verify whether the blocklist works or not. If it does not, then this is the next step, and johnath will need to review.
Comment 14 juan becerra [:juanb] 2011-11-14 16:52:19 PST
(In reply to Dave Townsend (:Mossop) from comment #12)
> (In reply to juan becerra [:juanb] from comment #11)
> > I see the same thing as Marcia: adding the entry in comment #8 to the
> > blocklist.xml does nothing to prevent the crash in Fx8 with version 7.5.2 of
> > the addon, whether I add the entry in the existing file in the installation
> > directory or adding a blocklist.xml in the user's profile folder.
> 
> Exactly what method are you using to test this? Just editing the
> blocklist.xml file in the profile won't actually have any effect unless you
> also do something like deleting extensions.ini and extensions.sqlite at the
> same time.

I edited and added the entry in the file in the installation folder. I then copied that to the profile folder. It didn't have any effect. I also deleted the extensions.ini and extension.sqlite, and that had no effect.

Could someone submit a try build with the proposed patch so we can try that?
Comment 15 Alex Keybl [:akeybl] 2011-11-14 17:15:19 PST
Let's kick off the try build, but if that's going to take longer than an hour to produce, we need to either come up with a local build sooner or have somebody help QA fix testing steps (without a rebuild).
Comment 16 Nick Thomas [:nthomas] 2011-11-14 17:51:58 PST
Created attachment 574490 [details] [diff] [review]
Patch for Fx8 ??

Looks like it's toolkit/xre/nsWindowsDllBlocklist.h on Fx8, rather than the .cpp.

https://tbpl.mozilla.org/?tree=Try&rev=980080381874
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/nthomas@mozilla.com-980080381874
Comment 17 Alex Keybl [:akeybl] 2011-11-14 17:56:29 PST
Thanks Nick.

Also, if anybody has suggestions for somebody to review this bug, it'd be greatly appreciated.
Comment 18 Kev Needham [:kev] 2011-11-14 18:30:18 PST
Johnath and vlad have done the previous reviews, so I'd defer to Johnath if he can be found.
Comment 19 Johnathan Nightingale [:johnath] 2011-11-14 19:20:01 PST
Comment on attachment 574474 [details] [diff] [review]
roboform dll block for toolkit/xre/nsWindowsDllBlocklist.cpp

This patch looks syntactically fine, BUT

- I haven't tested it so that would need to happen before we landed/shipped it
- Marcia uses "7.5.2.0" in comment 2 and this patch uses 7.6.2.0 - is that deliberate? (Judging from the rest of comment 2 I'd assume she just typo'd, but let's be sure)
- I'd normally insert a thing about how we don't typically DLL blocklist extensions since they can be blocked with the addon blocklist which is more user-friendly, but from the sounds of it RoboForm might be hacking around that
- the aforementioned makes me grumpy
- We don't seem quite clear yet on whether our blocklist.xml tests have affirmatively ruled out that option, there's back and forth in this bug about how to test it - we should be sure
- TIL that Ehsan moved the blocklist from a .h to a .cpp in bug 648581, which landed September 19. By my reckoning that makes Nick right, and we'd want his patch (against the .h file) on FF8, but Kev's patch on FF9 and up. Still, someone should double check my math, BECAUSE:
- I just got off 12 hours of air travel and 4 days of jetlag, and the thought of me in the code review path of a release is terrifying right now so let's go through this list again and be extra sure, please.
Comment 20 Marcia Knous [:marcia - use ni] 2011-11-14 19:27:43 PST
I was testing with that 7.5.2 version since that is a known version that crashes and I was trying to reproduce the startup crash problem. Bug 702321#c3 has the versions that are still causing crashes. Note that in that dataset there is 1 person that crashed using 7.6.2 despite the fact that Bug 691271 claims that 7.6.2 version fixed the crashing problem.

(In reply to Johnathan Nightingale [:johnath] from comment #19)
> Comment on attachment 574474 [details] [diff] [review] [diff] [details] [review]
> roboform dll block for toolkit/xre/nsWindowsDllBlocklist.cpp
> 
> This patch looks syntactically fine, BUT
> 
> - I haven't tested it so that would need to happen before we landed/shipped
> it
> - Marcia uses "7.5.2.0" in comment 2 and this patch uses 7.6.2.0 - is that
> deliberate? (Judging from the rest of comment 2 I'd assume she just typo'd,
> but let's be sure)
Comment 21 Alex Keybl [:akeybl] 2011-11-14 19:53:47 PST
Created attachment 574517 [details] [diff] [review]
changed the version to 7.6.1.0

Nick's patch but with an upper bound of 7.6.1.0 since we haven't been able to reproduce on 7.6.2.0.
Comment 22 Marcia Knous [:marcia - use ni] 2011-11-14 19:59:02 PST
I tested Roboform 7.6.2 just to make sure, and it does not crash when attaching to the Firefox process.
Comment 23 Daniel Holbert [:dholbert] 2011-11-14 20:28:37 PST
Pushed latest patch to try, at Alex's request:
 https://tbpl.mozilla.org/?tree=Try&rev=4d03924dbec6
Comment 24 John O'Duinn [:joduinn] (please use "needinfo?" flag) 2011-11-14 23:40:18 PST
before the "go to build 8.0.1", we need to also land this fix on relbranch  GECKO80_2011110416_RELBRANCH in http://hg.mozilla.org/releases/mozilla-release.
Comment 25 Alex Keybl [:akeybl] 2011-11-15 00:47:37 PST
Comment on attachment 574517 [details] [diff] [review]
changed the version to 7.6.1.0

[Triage Comment]
Confirmed working - let's get this into an 8.0.1.
Comment 26 Nick Thomas [:nthomas] 2011-11-15 00:54:29 PST
Comment on attachment 574517 [details] [diff] [review]
changed the version to 7.6.1.0

http://hg.mozilla.org/releases/mozilla-release/rev/6e453b4f7056
Comment 27 Kev Needham [:kev] 2011-11-15 05:27:02 PST
We should also be blocking the extension per comment #8 for consistency. I'd recommend a hardblock for 7.6.1 and below for Firefox 8.0a1 and above given that we're blocking the dll as well, without which Roboform won't work

Wil/Jorge, could you stage the block for testing, and we can ideally get QA finished and push it to prod this aft?

<emItem id="{22119944-ED35-4ab1-910B-E619EA06A115}">
  <versionRange minVersion="0.1" maxVersion="7.6.1">
	<targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
	  <versionRange minVersion="8.0a1" maxVersion="*"/>
	</targetApplication>
  </versionRange>
</emItem>
Comment 28 Robert Kaiser 2011-11-15 05:54:03 PST
(In reply to Johnathan Nightingale [:johnath] from comment #19)
> - I'd normally insert a thing about how we don't typically DLL blocklist
> extensions since they can be blocked with the addon blocklist which is more
> user-friendly, but from the sounds of it RoboForm might be hacking around
> that
> - the aforementioned makes me grumpy


Just to make things clear, Roboform is from all I know an externally installed application that runs on the system. It just provides an add-on as well.
Comment 29 Jorge Villalobos [:jorgev] 2011-11-15 07:51:20 PST
I added the block on staging. Please verify.
Comment 30 Kev Needham [:kev] 2011-11-15 07:52:39 PST
Just a reminder for blocklist testing please see:

https://wiki.mozilla.org/Blocklisting/Testing#Testing_Staged_Blocklist
Comment 31 Kev Needham [:kev] 2011-11-15 09:38:04 PST
In testing discovered the blocklist in place affects all versions of Firefox, not just 8.0a1 and above.

      <emItem  blockID="i45" id="{22119944-ED35-4ab1-910B-E619EA06A115}">
                        <versionRange  minVersion="0.1" maxVersion="7.6.1">
                    </versionRange>
                  </emItem>

(In reply to Jorge Villalobos [:jorgev] from comment #29)
> I added the block on staging. Please verify.
Comment 32 Jorge Villalobos [:jorgev] 2011-11-15 10:16:00 PST
I just added the application restriction on staging (the admin interface is kinda confusing). Please test again.
Comment 33 Kev Needham [:kev] 2011-11-15 12:33:54 PST
Tested with Windows XP staring with Firefox 7.0.1 and Roboform 7.6.1

- On Firefox 7.0.1 Roboform was not blocked.
- Initiated update to 8.0, and got the third-party update screen
- Enabled the Roboform extension and was informed that the extension would be enabled when a compatible version was available
- Roboform 7.6.1 was hardblocked for security/stability with link to blocklist (that 404'd)

Updated to Roboform 7.6.2 and the block was lifted/roboform was enabled.

Looks good for XP, anyone else test it out? Just need to make sure we push an entry for the reason on the blocklist as well.
Comment 34 Jorge Villalobos [:jorgev] 2011-11-15 12:37:53 PST
(In reply to Kev [:kev] Needham from comment #33)
> - Roboform 7.6.1 was hardblocked for security/stability with link to
> blocklist (that 404'd)

Was that link pointing to the production site? I can see the entry on stage: https://addons-dev.allizom.org/en-US/firefox/blocked/

BTW, I could use a second opinion on the text in that entry. I kept it very brief.
Comment 35 Alex Keybl [:akeybl] 2011-11-15 13:34:20 PST
If we can reproducibly confirm that 7.0.1+RF7.6.2->8.0.1 causes a startup crash, we need to

* get a crash signature if available (or confirm it is not available)
* look at rf-firefox.dll and roboform.dll and make sure that on 7.6.2 they aren't mistakenly versioned as 7.6.1 or lower
* confirm whether the updated add-on blocklist Jorge did (not the DLL blocklist) is being picked up in QA testing
  - if the add-on blocklist prevents a crash on 7.6.2 for some reason, whether our users will get the blocklist prior to updating or on 8.0.1 first launch
Comment 36 Alex Keybl [:akeybl] 2011-11-15 13:53:06 PST
And I just want explicit confirmation here that the same crash does not happen when repro steps are changed to update to 8.0 (instead of 8.0.1) if possible.
Comment 37 Alex Keybl [:akeybl] 2011-11-15 14:29:56 PST
One other possibility is that XP RF installs have differently named DLL files than on 7 (and we thus could have blocked one DLL but not the other). Can we confirm what DLLs are being installed on XP? When we know, we should also dump versions from those DLLs.

Sadly, I only have Win7/OS X to test.
Comment 38 juan becerra [:juanb] 2011-11-15 14:34:46 PST
On Windows XP, we've seen an issue where if you start with Fx7.0.1 and Roboform version 7.6.2 (which is not supposed to be blocklisted), and you then install 8.0.1 on top (pave over installation), Firefox doesn't start. There is no crash. This behavior is different if you use Fx8.0, in that the resulting 8.0 build launches properly.

We've reproduced this on multiple VMs and hardware.

We need someone who understands the code to help us diagnose the problem.

I'll add the information requested by Alex in commment #35, but from what we know there is no startup crash.
Comment 39 juan becerra [:juanb] 2011-11-15 14:38:20 PST
You can download versions of the Roboform add-on here: http://www.oldapps.com/roboform.php
Comment 40 Jonas Sicking (:sicking) PTO Until July 5th 2011-11-15 15:40:40 PST
If you install roboform 7.6.2, can you check what version the following two dlls have:

rf-firefox.dll
roboform.dll

I *think* you can check the version by simply right-clicking the dll file and selecting properties or info or some such.
Comment 41 juan becerra [:juanb] 2011-11-15 15:53:20 PST
Jonas, in version 7.6.2, the only meaningful version number in the properties dialog says 7-6-2 for roboform.dll. I couldn't find the rf-firefox.dll anywhere.
Comment 42 Kev Needham [:kev] 2011-11-15 16:31:34 PST
Created attachment 574727 [details]
roboform.dll 7.6.2.0

I'm seeing the hang with 7.6.2.0 with roboform.dll on Windows XP. If it's also with 7.6.3.0, then it may be an issue that doesn't have a fix currently. We could BL all versions of the roboform.dll, but then they'd have to either change the filename with the fix, or users wouldn't have access to the extension/features of the DLL until the next release.
Comment 43 Alex Keybl [:akeybl] 2011-11-15 16:44:01 PST
I'm about to attach DLL dumps for FF7.0.1/8.0/8.0.1 with 7.6.2 installed. I used the following command

Listdlls.exe -v firefox > ff{version}_loaded.txt

On Windows 7, at least, the DLLs are located at

C:\Program Files\Siber Systems\AI RoboForm\RoboForm.dll
C:\Program Files\Siber Systems\AI RoboForm\Firefox\rf-firefox.dll

and both have version

Version:        7.6.2.0

Nothing jumps out at me, but we need to do the same for WinXP.
Comment 44 Alex Keybl [:akeybl] 2011-11-15 16:44:38 PST
Created attachment 574730 [details]
FF7.0.1+RF7.6.2 loaded DLLs
Comment 45 Alex Keybl [:akeybl] 2011-11-15 16:45:21 PST
Created attachment 574731 [details]
FF8.0+RF7.6.2 loaded DLLs
Comment 46 Alex Keybl [:akeybl] 2011-11-15 16:46:25 PST
Created attachment 574732 [details]
FF8.0.1+RF7.6.2 loaded DLLs
Comment 47 Alex Keybl [:akeybl] 2011-11-15 16:52:17 PST
(In reply to Kev [:kev] Needham from comment #42)
> Created attachment 574727 [details]
> roboform.dll 7.6.2.0
> 
> I'm seeing the hang with 7.6.2.0 with roboform.dll on Windows XP. If it's
> also with 7.6.3.0, then it may be an issue that doesn't have a fix
> currently. We could BL all versions of the roboform.dll, but then they'd
> have to either change the filename with the fix, or users wouldn't have
> access to the extension/features of the DLL until the next release.

It's very curious that this isn't happening with FF8.0 on XP though - and it would be a shame to blocklist working versions of RoboForm.

I'd like to get a better understanding of what could cause such different behavior between FF8 and FF8.0.1 before taking action.
Comment 48 Kev Needham [:kev] 2011-11-15 16:56:45 PST
On XP the addon is installed to the user's profile directory, not Program Files. Not sure if that has anything to do with it, but the example I outlined has the plugin installed in c:\Documents and Settings\Administrator\Application Data\RoboForm (that is me grasping at straws)
Comment 49 juan becerra [:juanb] 2011-11-15 17:15:09 PST
Created attachment 574746 [details]
Fx7.0.1+Roboform7.6.2 on XP
Comment 50 juan becerra [:juanb] 2011-11-15 17:16:50 PST
Created attachment 574748 [details]
Fx8.0+Roboform7.6.2 on XP
Comment 51 juan becerra [:juanb] 2011-11-15 17:22:06 PST
Created attachment 574751 [details]
Fx8.0.1+Roboform7.6.2 on XP
Comment 52 Alex Keybl [:akeybl] 2011-11-15 17:39:40 PST
It doesn't appear as if we're mistakenly blocking any DLL loads on XP in any of the dumps Juan attached.

We're now going to verify the previous assumption that an add-on blocklist alone on 8.0 doesn't resolve the startup crashes in old RF versions (which would preclude the need for a DLL blocklist addition). If the assumption was wrong, we should move ahead with that change alone (no DLL blocklist addition).
Comment 53 Marcia Knous [:marcia - use ni] 2011-11-15 18:23:18 PST
Here are some testing results from the extension block:

Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0
7.6.2 - Does not Block

Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0
7.6.1 Does Block

Firefox 8.0. 7.6.0 - Mohammed
Does Block

Tested Same Scenario as Kev:

Tested with Windows XP starting with Firefox 7.0.1 and Roboform 7.6.1

- On Firefox 7.0.1 Roboform was not blocked. It was disabled but I could enable it.
- Updated to 8.0, and got the third-party update screen
- Enabled the Roboform extension
- Roboform 7.6.1 was hardblocked for security/stability with link to blocklist (that 404'd)

Updated to Roboform 7.6.2 and Roboform was enabled.
Comment 54 Marcia Knous [:marcia - use ni] 2011-11-15 18:42:10 PST
Juan asked me to perform a test:

1. Install Roboform 7.5.2.
2. Launch Firefox 8 (Previously I had changed the blocklist URL to the staging server).
3. Initiate the ping. Firefox is now hard blocked.
4. Close Firefox and change the Browser Integration settings to "Attach Roboform to Firefox".
5. Firefox still crashes on startup upon relaunch.
Comment 55 Marcia Knous [:marcia - use ni] 2011-11-15 18:57:02 PST
Just for some context around the extension correlation for each signature:

DbgBreakPoint:
42% (394/933) vs.   1% (731/104696) {22119944-ED35-4ab1-910B-E619EA06A115} (Roboform Toolbar for Firefox, https://addons.mozilla.org/addon/750)

DebugBreak:
38% (135/352) vs.   1% (731/104696) {22119944-ED35-4ab1-910B-E619EA06A115} (Roboform Toolbar for Firefox, https://addons.mozilla.org/addon/750)

kernelbase.dll@0x31f66:

30% (11/37) vs.   1% (731/104696) {22119944-ED35-4ab1-910B-E619EA06A115} (Roboform Toolbar for Firefox, https://addons.mozilla.org/addon/750)
Comment 56 Alex Keybl [:akeybl] 2011-11-16 09:21:57 PST
I'm currently confirming that the try build in https://bugzilla.mozilla.org/show_bug.cgi?id=700835#c66 includes only the fix for 700835 and is based off of 8, so that we can try to isolate the new crashers.


In the meantime, we should kick off try builds of 8.0+699134 and 8.0+700835 in order to help us isolate the issue.
Comment 57 Justin Wood (:Callek) 2011-11-16 09:56:43 PST
(In reply to Alex Keybl [:akeybl] from comment #56)
> In the meantime, we should kick off try builds of 8.0+699134 and 8.0+700835
> in order to help us isolate the issue.

Done, pushed separately to try, with --post-to-bugzilla set to this bug from directly on top of the FIREFOX_8_0_RELEASE tag.

http://hg.mozilla.org/try/rev/c2a0303d48bf
http://hg.mozilla.org/try/rev/d45763120aad
Comment 59 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-11-16 12:19:32 PST
Firefox appears to be crashing with a stack overflow exception:

First-chance exception at 0x7c90e8e5 (ntdll.dll) in firefox.exe: 0xC00000FD: Stack overflow.

 	ntdll.dll!_RtlDebugAllocateHeap@12()  + 0xaf bytes	
 	ntdll.dll!_RtlAllocateHeapSlowly@12()  + 0x31624 bytes	
 	ntdll.dll!_RtlAllocateHeap@12()  + 0x9b48 bytes	
 	ntdll.dll!_RtlDosPathNameToNtPathName_Ustr@16()  + 0x93 bytes	
 	ntdll.dll!_RtlDoesFileExists_UstrEx@8()  + 0x1c bytes	
 	ntdll.dll!_RtlDoesFileExists_UEx@8()  + 0x27 bytes	
 	ntdll.dll!_RtlDosSearchPath_UEx@28()  + 0x1f bytes	
 	ntdll.dll!_LdrpCheckForLoadedDll@20()  + 0x17d bytes	
 	ntdll.dll!_LdrGetDllHandleEx@20()  + 0x1cb bytes	
 	ntdll.dll!_LdrGetDllHandle@16()  + 0x18 bytes	
 	kernel32.dll!_LoadLibraryExW@12()  + 0x22e bytes	
 	fshook32.dll!100320eb() 	

fshook32 is part of F-Secure. Do we know if this crash only happens with F-secure installed also?

below here the stack is unreliable, but it may involve a loop of these calls:

 	ntdll.dll!_NtQueryInformationProcess@20()  + 0xc bytes	
 	ntdll.dll!_NtSetInformationProcess@16()  + 0xc bytes	
 	version.dll!_GetFileVersionInfoSizeW@8()  + 0x31 bytes	
 	xul.dll!patched_LdrLoadDll(wchar_t * filePath, unsigned long * flags, _UNICODE_STRING * moduleFileName, void * * handle)  + 0x42486 bytes	C++

I'm going to keep debugging.
Comment 60 Marcia Knous [:marcia - use ni] 2011-11-16 12:22:02 PST
The lab machine happens to have FSecure, but I believe Waverly and Juan were reproducing the issue without FSecure on their machines.
Comment 61 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-11-16 13:05:53 PST
The iloop is apparently trying to load "C:\Program Files\Siber Systems\AI RoboForm\RoboForm.dll"

Apparently the call to GetFileVersionInfoSize here is recursing.

http://hg.mozilla.org/releases/mozilla-release/file/FIREFOX_8_0_1_BUILD1/toolkit/xre/nsWindowsDllBlocklist.cpp#l180

I'm think I'm going to try uninstalling fsecure to see if I can get better stacks.
Comment 62 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-11-16 13:53:18 PST
Without fsecure the stack loop is pretty straightforward:

 	xul.dll!patched_LdrLoadDll(wchar_t * filePath, unsigned long * flags, _UNICODE_STRING * moduleFileName, void * * handle)  + 0x42486 bytes	C++
 	kernel32.dll!_SetErrorMode@4()  + 0x32 bytes	
 	version.dll!_GetFileVersionInfoSizeW@8()  + 0x31 bytes	
>	xul.dll!patched_LdrLoadDll(wchar_t * filePath, unsigned long * flags, _UNICODE_STRING * moduleFileName, void * * handle)  + 0x42486 bytes	C++
 	kernel32.dll!_SetErrorMode@4()  + 0x32 bytes	
 	version.dll!_GetFileVersionInfoSizeW@8()  + 0x31 bytes	
 	xul.dll!patched_LdrLoadDll(wchar_t * filePath, unsigned long * flags, _UNICODE_STRING * moduleFileName, void * * handle)  + 0x42486 bytes	C++
 	kernel32.dll!_SetErrorMode@4()  + 0x32 bytes	
 	version.dll!_GetFileVersionInfoSizeW@8()  + 0x31 bytes	

Now this is still a little broken, but I basically see in the assembly that in some cases GetFileVersionInfoSizeW itself calls LoadLibraryEx. This makes me very worried about any version-specific blocklist perhaps causing this failure mode.
Comment 63 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-11-16 14:03:04 PST
Yes, the first things GetFileVersionInfoSize does (on WinXP at least) is call LoadLibraryEx with LOAD_LIBRARY_AS_DATAFILE. It then uses FindResource to get the version resource.

I don't know why other versions of Windows don't show this bug, perhaps because they do something different in GetFileVersionInfoSize. In any case, we could possibly work around this problem by skipping all the blocklisting checks if the _AS_DATAFILE flags are passed.

I will next try and figure out why breakpad isn't functioning.
Comment 64 :Ehsan Akhgari 2011-11-16 14:06:54 PST
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #63)
> I don't know why other versions of Windows don't show this bug, perhaps
> because they do something different in GetFileVersionInfoSize. In any case,
> we could possibly work around this problem by skipping all the blocklisting
> checks if the _AS_DATAFILE flags are passed.

I think we should disable blocklisting completely for all DLL loads as data files.  Patch forthcoming.
Comment 65 juan becerra [:juanb] 2011-11-16 14:23:17 PST
Created attachment 575000 [details]
List of dlls loaded in scenarios listed in testing matrix using Fx8+699134 try-server build.

In all cases, 7.6.1, 7.6.2, 7.6.3, if I chose not to enable the add-on, Firefox launched fine. If I enabled the third-party addons in the dialog, Firefox didn't launch in 7.6.2 and 7.6.3. In the case of 7.6.1 it launched ok, with an error about not finding some robo... file.
Comment 66 :Ehsan Akhgari 2011-11-16 14:50:06 PST
Created attachment 575005 [details] [diff] [review]
Don't attempt to block DLLs loaded as data files
Comment 67 :Ehsan Akhgari 2011-11-16 15:12:29 PST
Try server job based on the mozilla-release repository: https://tbpl.mozilla.org/?tree=Try&rev=2dd7ebd86902

This should give us an officially branded 8.0.1 build with my patch applied to it.
Comment 68 Mozilla RelEng Bot 2011-11-16 15:30:32 PST
Try run for 58efa7592dcb is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=58efa7592dcb
Results (out of 2 total builds):
    exception: 2
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-58efa7592dcb
Comment 69 :Ehsan Akhgari 2011-11-16 15:32:42 PST
Comment on attachment 575005 [details] [diff] [review]
Don't attempt to block DLLs loaded as data files

Here's a risk assessment for this patch, as Alex requested.

If something goes wrong with this patch, we would potentially end up not block-listing some of the DLLs that we want to blocklist.  The implications are potential crashes or security vulnerabilities.

*However*, the chance of that happening is extremely low.  DLLs loaded as data files cannot execute code (unless they are already loaded somehow, in which case we lose with or without this patch), so loading blocklisted DLLs this way should not involve any risk as far as I can tell.

We definitely need QA to confirm that the DLL blocklisting still works with this patch for the list of DLLs which we currently blocklist (both versioned and non-versioned).  I will comment on the bug when the builds are available, so that QA can start testing them.
Comment 70 :Ehsan Akhgari 2011-11-16 15:33:34 PST
(In reply to Mozilla RelEng Bot from comment #68)
> Try run for 58efa7592dcb is complete.
> Detailed breakdown of the results available here:
>     https://tbpl.mozilla.org/?tree=Try&rev=58efa7592dcb
> Results (out of 2 total builds):
>     exception: 2
> Builds available at
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.
> com-58efa7592dcb

Please ignore this.  This was a job I pushed by mistake, and I cancelled it.
Comment 71 alexkeybl 2011-11-16 15:40:34 PST
I just took a look through the blocklist. Here's the list of non-malware DLLs that define a MAKE_VERSION version, and could therefore be affected

avgrsstx.dll - Antivirus vendor AVG
vksaver.dll - VKSaver, "a program to download some media content from Russian social networking site vkontakte.ru"
accelerator.dll - speedbit video accelerator

of these, the AVG one needs more investigation. I'm going to try to find out if more recent versions of AVG use this same DLL name.
Comment 72 :Ehsan Akhgari 2011-11-16 15:55:30 PST
(In reply to Alex Keybl from comment #71)
> I just took a look through the blocklist. Here's the list of non-malware
> DLLs that define a MAKE_VERSION version, and could therefore be affected
> 
> avgrsstx.dll - Antivirus vendor AVG
> vksaver.dll - VKSaver, "a program to download some media content from
> Russian social networking site vkontakte.ru"
> accelerator.dll - speedbit video accelerator
> 
> of these, the AVG one needs more investigation. I'm going to try to find out
> if more recent versions of AVG use this same DLL name.

Note that our blocklisting code actually fails to blocklist vksaver.dll properly, so that shouldn't be taken against this patch.
Comment 73 Alex Keybl [:akeybl] 2011-11-16 16:05:40 PST
To confirm our understanding of this issue, and get a feel for the population currently affected, we've filed bug 703131 to get crash data related to the above DLLs.

If our understanding is correct, I would expect these DLL versions to not come up in WinXP crashes from the last 7 days, but have a non-zero number on Vista/7.
Comment 74 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-11-16 17:22:18 PST
I don't understand comment 73. The blocklist *works*, so we shouldn't have crashes with that DLL at all. It's just that if we have a "blocklist particualar versions of a DLL" entry and that DLL is present (in any version!), Firefox will crash on Windows XP. So I don't *think* that crash stats has any useful information here.
Comment 75 [:Cww] 2011-11-16 17:28:53 PST
Ugh, and because it's a stack overflow (which has lots of other causes) it's not possible to pin it to a single signature (?)
Comment 76 Alex Keybl [:akeybl] 2011-11-16 17:29:33 PST
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #74)
> I don't understand comment 73. The blocklist *works*, so we shouldn't have
> crashes with that DLL at all. It's just that if we have a "blocklist
> particualar versions of a DLL" entry and that DLL is present (in any
> version!), Firefox will crash on Windows XP. So I don't *think* that crash
> stats has any useful information here.

The point of that query is to verify that

* There are 0 instances of the above DLLs in unrelated crashes on WinXP with FF7.0.1/8
* There is a non-zero number of instances of the above DLLs in unrelated crashes on Vista/Win7 with FF7.0.1/8

We'll then be able to use this data to back up our understanding of the issue.
Comment 77 Alex Keybl [:akeybl] 2011-11-16 17:30:40 PST
(In reply to [:Cww] from comment #75)
> Ugh, and because it's a stack overflow (which has lots of other causes) it's
> not possible to pin it to a single signature (?)

We don't have crash data for this - bsmedberg is looking into why we're not catching these startup crashes.
Comment 78 Alex Keybl [:akeybl] 2011-11-16 18:00:27 PST
We just got initial numbers back on the queries that should show no crash instances of XP with avgrsstx.dll - https://bugzilla.mozilla.org/show_bug.cgi?id=703131#c3

Looks like NT5.1 (older XP) does show up in the list, but NT5.2 (newer XP) does not. Please confirm if this is expected.
Comment 79 :Ehsan Akhgari 2011-11-16 18:24:07 PST
(In reply to Alex Keybl [:akeybl] from comment #78)
> Looks like NT5.1 (older XP) does show up in the list, but NT5.2 (newer XP)
> does not. Please confirm if this is expected.

Isn't NT 5.2 Windows 2003?
Comment 80 Alex Keybl [:akeybl] 2011-11-16 18:30:29 PST
I'm looking at https://en.wikipedia.org/wiki/Windows_NT#Releases to see NT versions. Looks like NT5.2 include x64 WinXP, amongst others.
Comment 81 Alex Keybl [:akeybl] 2011-11-16 18:39:41 PST
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-2dd7ebd86902/ - builds are now available for QA testing
Comment 82 Mozilla RelEng Bot 2011-11-16 18:50:30 PST
Try run for c2a0303d48bf is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=c2a0303d48bf
Results (out of 275 total builds):
    success: 226
    warnings: 20
    failure: 29
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/Callek@gmail.com-c2a0303d48bf
Comment 83 :Ehsan Akhgari 2011-11-16 18:51:58 PST
So, I tried the builds and I'm really puzzled at this point...

https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-c9ee27dad619/ is a *non-PGO* build *without* my fix.  Firefox does not crash at startup with this build, which surprises me, because I expect that it _should_.

https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-c7407b6fcfee/ is a *non-PGO* build *with* my fix.  Firefox does not crash at startup with this build, but this doesn't tell us anything since the previous build doesn't crash either.

https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-2dd7ebd86902/ (comment 81) is a *PGO* build *with* my fix.  Firefox does not crash at startup with this build.  This should be equivalent to the current 8.0.1 candidate builds with my fix on top.  But the above makes me doubt whether the fix is really working, or whether the issue is being bypassed because of some unknown reason.

I guess I will generate a dummy build based on https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-2dd7ebd86902/ but without my fix to see if that crashes.  If that does not crash, then I will be out of ideas on whether my fix really helps or not...
Comment 84 :Ehsan Akhgari 2011-11-16 18:53:43 PST
(In reply to Ehsan Akhgari [:ehsan] from comment #83)
> I guess I will generate a dummy build based on
> https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.
> com-2dd7ebd86902/ but without my fix to see if that crashes.  If that does
> not crash, then I will be out of ideas on whether my fix really helps or
> not...

Pushed http://tbpl.mozilla.org/?tree=Try&rev=5ab1f2b20eb4 for this.
Comment 85 Mozilla RelEng Bot 2011-11-16 19:10:25 PST
Try run for 2dd7ebd86902 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=2dd7ebd86902
Results (out of 47 total builds):
    success: 40
    warnings: 3
    failure: 4
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-2dd7ebd86902
Comment 86 juan becerra [:juanb] 2011-11-16 23:04:14 PST
Results on XP using tryserver build in comment #85 (starts with addon version):
* 761, addons disabled: OK, robo disabled
* 761, addons enabled: OK, robo ok
* 762, addons disabled: OK, robo disabled
* 762, addons enabled: OK, robo ok
* 763, addons disabled: OK, robo disabled
* 763, addons enabled: OK, robo ok
* 752 (known crasher), addons disabled: crash (caught)

I have the archive of files with the loaded dlls for the scenarios above, if needed.
Comment 87 Alex Keybl [:akeybl] 2011-11-16 23:30:01 PST
(In reply to juan becerra [:juanb] from comment #86)
> Results on XP using tryserver build in comment #85 (starts with addon
> version):
> * 752 (known crasher), addons disabled: crash (caught)

I've confirmed that 7.5.2 has properly versioned DLLs (just in case). Looks like a new regression.

We've been using http://www.oldapps.com/roboform.php?old_roboform=6651 for the 7.5.2 download. Juan let me know that that the crash signature he got was https://crash-stats.mozilla.com/report/index/bp-eb5ec8c8-a4e2-477c-8dc3-ca6d42111116
Comment 88 juan becerra [:juanb] 2011-11-17 00:06:30 PST
Results using Win7:
* 761, addons disabled: OK, robo disabled
* 761, addons enabled: OK, robo ok
* 762, addons disabled: OK, robo disabled
* 762, addons enabled: OK, robo ok
* 763, addons disabled: OK, robo disabled
* 763, addons enabled: OK, robo ok
* 752, addons disabled: crash

http://crash-stats.mozilla.com/report/index/bp-b9ccd34f-52bb-4718-bd2a-79f902111116
Comment 89 juan becerra [:juanb] 2011-11-17 00:09:12 PST
Created attachment 575112 [details]
dlls loaded in scenarios on Win7, using trybuild in comment #85,
Comment 90 juan becerra [:juanb] 2011-11-17 00:11:43 PST
Created attachment 575113 [details]
dlls loaded in scenarios on XP, using trybuilds in comment #85
Comment 91 Robert Kaiser 2011-11-17 03:48:29 PST
(In reply to Alex Keybl [:akeybl] from comment #78)
> We just got initial numbers back on the queries that should show no crash
> instances of XP with avgrsstx.dll -
> https://bugzilla.mozilla.org/show_bug.cgi?id=703131#c3
> 
> Looks like NT5.1 (older XP) does show up in the list, but NT5.2 (newer XP)
> does not. Please confirm if this is expected.

5.1 is standard 32bit XP. 5.2 is usually Windows Server 2003, but XP 64bit may report as that as well. In the end, there are _very_ few instances of 5.1 in the data as well compared to 6.x (Vista/Win7), so I guess we can safely say we have no problem there on XP.
Comment 92 :Ehsan Akhgari 2011-11-17 06:55:32 PST
Here's why I could not reproduce the crashes with my try server build.  The blocklist patch landed only on the relbranch and not on the default branch: http://hg.mozilla.org/releases/mozilla-release/rev/6e453b4f7056.  So, my builds, which were not based on the relbranch did not include the blocklist, and hence did not crash.

Landing patches only on relbranches and not the default branch is very confusing, and it causes us to potentially miss them if we ever create a new branch.  I went ahead and landed the patch on the default branch as well: http://hg.mozilla.org/releases/mozilla-release/rev/89f6d57bf81f

I'm currently testing a local build with the blocklisting change to see whether I can reproduce the crash.
Comment 93 :Ehsan Akhgari 2011-11-17 07:34:03 PST
OK, with the blocklist change in my local build, I can confirm that it crashes at startup without my fix, but it doesn't crash with my fix.  Therefore, my patch does really fix the startup crash.
Comment 94 :Ehsan Akhgari 2011-11-17 13:22:06 PST
Builds available for testing here: <https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-83a386f3f4fc/>
Comment 95 :Ehsan Akhgari 2011-11-17 15:42:21 PST
I can reproduce a crash with XP and Roboform 7.6.2 with my patch.  I'm trying to debug it...
Comment 96 :Ehsan Akhgari 2011-11-17 17:35:04 PST
I've got an extremely reliable STR:

1. Open about:config.
2. Open the web console (Ctrl+Shift+K)
3. Paste in the following JS code:

Components.utils.import("resource://gre/modules/ctypes.jsm"); var lib = ctypes.open("C:\\Program Files\\Siber Systems\\AI RoboForm\\Firefox\\rf-firefox.dll")
Comment 97 :Ehsan Akhgari 2011-11-17 17:38:21 PST
(In reply to Ehsan Akhgari [:ehsan] from comment #96)
> I've got an extremely reliable STR:
> 
> 1. Open about:config.
> 2. Open the web console (Ctrl+Shift+K)
> 3. Paste in the following JS code:
> 
> Components.utils.import("resource://gre/modules/ctypes.jsm"); var lib =
> ctypes.open("C:\\Program Files\\Siber Systems\\AI
> RoboForm\\Firefox\\rf-firefox.dll")

Except that it's not quite reliable.  Windows is really making this game harder than it needs to be!
Comment 98 :Ehsan Akhgari 2011-11-17 18:34:49 PST
Created attachment 575358 [details] [diff] [review]
Protect against reentrancy

Turns out that Windows doesn't call LdrLoadDll with the original flags passed to LoadLibrary(Ex).  This patch does the hard thing of actually checking for re-entrancy based on a per-thread stack of the DLL names being processed in LdrLoadDll.

This seems to fix the crash for me, I've pushed a try server job: https://tbpl.mozilla.org/?tree=Try&rev=db253b723c92
Comment 99 :Ehsan Akhgari 2011-11-17 20:25:45 PST
Alex pinged me cause the build failed.  Seems to be a missing header.  I pushed another patch which _should_ fix it: https://tbpl.mozilla.org/?tree=Try&rev=67903485b4c2 (but I pushed it without testing because I don't have access to a Windows build machine right now).

If this fails as well, and somebody is awake, please feel free to add as many headers as it would take to make this compile and push on my behalf.  :)
Comment 100 :Ehsan Akhgari 2011-11-17 20:35:10 PST
I'm going to sleep now as I'm struggling with a migraine attack.  :(  For the record, I'd be fine with sicking (or somebody else knowledgeable enough to r+ this, and for this to land pending that r+ and the green light from QA.

I asked Alex to go to build with this given the above.  But I still would like bsmedberg to take a look at this, and I asked Alex that if he doesn't like this patch when he looks at this tomorrow, we should pull the plug on the release.

Sorry if my personal conditions interfered with this tonight, but I feel fairly confident in this patch and I hope that we can go to build with this.  I've asked Alex to call me in the unfortunate case that this breaks down in a way which requires my attention.  Anybody else who has my phone number is also welcome to that offer.  :)
Comment 101 Alex Keybl [:akeybl] 2011-11-17 21:50:18 PST
Looks like the latest build failed as well: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-67903485b4c2/try-win32/try-win32-build1561.txt.gz

Let's hold off on going to build for 8.0.1 build2 till the morning. If somebody could resolve the latest build failure and push out another try build before 8AM/9AM PT tomorrow morning, it'd be much appreciated.
Comment 102 Mark Banner (:standard8) 2011-11-18 00:07:05 PST
(In reply to Alex Keybl [:akeybl] from comment #101)
> Looks like the latest build failed as well:
> https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.
> com-67903485b4c2/try-win32/try-win32-build1561.txt.gz

I think I know what the issue is, so I'm working on a additional push. Currently cloning try repo.
Comment 103 Mark Banner (:standard8) 2011-11-18 01:00:38 PST
I've hopefully pushed a fix with Ehsan's patch. Relevant links:

https://tbpl.mozilla.org/?tree=Try&rev=d8e87b590762

Updated patch: https://hg.mozilla.org/try/rev/0e496d96de38
Comment 104 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-11-18 03:25:39 PST
Comment on attachment 575358 [details] [diff] [review]
Protect against reentrancy

this should definitely not be a map to nsCAutoString for several reasons:

1) this should cause noticeable shutdown leaks of autostring objects as reported by tracerefcnt
2) autostrings are for stack values, you would want nsCString
3) dllName is in scope on the stack, why not just store the const char* directly in the map, e.g.

map<DWORD, const char*>

Is there a particular reason we can't use __declspec(thread) instead of the hand-rolled map?
Comment 105 Mark Banner (:standard8) 2011-11-18 05:04:08 PST
(In reply to Mark Banner (:standard8) from comment #103)
> I've hopefully pushed a fix with Ehsan's patch. Relevant links:
> 
> https://tbpl.mozilla.org/?tree=Try&rev=d8e87b590762
> 
> Updated patch: https://hg.mozilla.org/try/rev/0e496d96de38

Builds are now available here:

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bugzilla@standard8.plus.com-d8e87b590762/try-win32/
Comment 106 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-11-18 05:29:05 PST
Also the TLS map needs to be protected by a lock. It looks like __declspec(thread) is not usable because this code can be loaded via LoadLibrary. I'm going to try cooking up a patch now.
Comment 107 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-11-18 06:13:34 PST
Trying my revised version here: https://tbpl.mozilla.org/?tree=Try&rev=98abf936800b
Builds will be at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bsmedberg@mozilla.com-98abf936800b

Patch is here: https://hg.mozilla.org/try/rev/c988150c6903
Comment 108 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-11-18 06:14:26 PST
Created attachment 575438 [details] [diff] [review]
Revised sentinel
Comment 109 Virgil Dicu [:virgil] [QA] 2011-11-18 06:28:31 PST
Tested using the builds in comment 105 on Windows XP with the STR after which Firefox wouldn't start with the build from Wednesday.

1. Install Firefox 7.0.1
2. Install and enable Roboform 7.6.2
3. Pave-over install Try Build 8.0.1.
4. Start Firefox.

Firefox starts normally with this build

We did not check with other versions however yet.

So I understand that other builds will be available? Should we focus on testing the other test scenarios withthe try builds to be added, as per comment 108?
Comment 110 :Ehsan Akhgari 2011-11-18 06:58:25 PST
Comment on attachment 575438 [details] [diff] [review]
Revised sentinel

Please remove the InitializeStatics call from the ctor. The current patch reinitializes the map once for every object, so I don't think that it can actually protect against reentrancy. r=me with that.

Also as a nit, I would add back some of the comments that I had about why we're rolling our own TLS, etc.
Comment 111 :Ehsan Akhgari 2011-11-18 07:00:41 PST
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #107)
> Trying my revised version here:
> https://tbpl.mozilla.org/?tree=Try&rev=98abf936800b
> Builds will be at
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bsmedberg@mozilla.
> com-98abf936800b
> 
> Patch is here: https://hg.mozilla.org/try/rev/c988150c6903

I think you should pudh another try patch with my comment addredsed for QA to test.
Comment 112 Vlad [QA] 2011-11-18 07:07:25 PST
Hi Ehsan.
This means that we have to again wait for another build?

(In reply to Ehsan Akhgari [:ehsan] from comment #111)
> (In reply to Benjamin Smedberg  [:bsmedberg] from comment #107)
> > Trying my revised version here:
> > https://tbpl.mozilla.org/?tree=Try&rev=98abf936800b
> > Builds will be at
> > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bsmedberg@mozilla.
> > com-98abf936800b
> > 
> > Patch is here: https://hg.mozilla.org/try/rev/c988150c6903
> 
> I think you should pudh another try patch with my comment addredsed for QA
> to test.
Comment 113 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-11-18 07:14:34 PST
https://tbpl.mozilla.org/?tree=Try&rev=bb7ff80b8d63
and http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bsmedberg@mozilla.com-bb7ff80b8d63

please ignore the builds from comment 107, which I think I've cancelled
Comment 114 :Ehsan Akhgari 2011-11-18 10:47:30 PST
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #113)
> https://tbpl.mozilla.org/?tree=Try&rev=bb7ff80b8d63
> and
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bsmedberg@mozilla.
> com-bb7ff80b8d63
> 
> please ignore the builds from comment 107, which I think I've cancelled

These try builds are now available.
Comment 115 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-11-18 11:31:48 PST
There is a bug in this patch discovered in testing (need an extra null-check). Yet more new builds:

https://tbpl.mozilla.org/?tree=Try&rev=e55c5b3c6a74
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bsmedberg@mozilla.com-e55c5b3c6a74
Comment 116 Alex Keybl [:akeybl] 2011-11-18 15:15:36 PST
The build is now available for QA testing: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bsmedberg@mozilla.com-e55c5b3c6a74/try-win32/
Comment 117 juan becerra [:juanb] 2011-11-18 16:50:29 PST
We've tested this on XP and Win7 environments, with add-on versions 7.6.3, 7.6.2, 7.6.1, 7.5.2. We no longer get startup crashes.

The only glitch I noticed was that Process Explorer would report the roboform.dll as being loaded immediately after launch in the case where I had installed add-on version 7.5.2. If I looked later, the dll wasn't there.

Aside from that I think this trybuild looks good. You can see the results at the bottom: https://etherpad.mozilla.org/Roboform-Blocklist-Testing
Comment 118 Alex Keybl [:akeybl] 2011-11-18 17:03:04 PST
Comment on attachment 575358 [details] [diff] [review]
Protect against reentrancy

Fantastic news - let's make sure both of these patches are on all branches (including mozilla-release) as soon as possible. Our go to build is Sunday afternoon to allow this some time to bake on the nightly, so if this needs any more testing, please go for it.
Comment 119 Alex Keybl [:akeybl] 2011-11-18 17:04:16 PST
Comment on attachment 575438 [details] [diff] [review]
Revised sentinel

The correct patch this time.
Comment 120 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2011-11-18 18:26:32 PST
Created attachment 575616 [details] [diff] [review]
Final version with sentinel

I will not have the opportunity to push this tonight, but I welcome somebody else doing it. I'll try to do it early tomorrow if necessary.
Comment 122 Jorge Villalobos [:jorgev] 2011-11-19 06:20:06 PST
Roboform has been blocked in production, as specified in Comment #27.
Comment 123 Jorge Villalobos [:jorgev] 2011-11-19 06:46:23 PST
******** ATTENTION: READ BEFORE COMMENTING *********

If your Roboform extension has been blocked, all you need to do in order to fix the problem is install the latest version.

Only versions 7.6.1 and lower have been blocked because they were causing many crashes for Firefox users. Versions 7.6.2 and above should install and work correctly.
Comment 124 PAdam 2011-11-19 12:07:30 PST
Oh, but this is REALLY nice!!!!

The original document says
Why was it blocked?
    This add-on causes a high volume of crashes in Firefox versions 8 and above.
Who is affected?
    Users of Roboform versions 7.6.1 and lower using Firefox versions 8.0a1 and higher.

It so happens that I'm still using FF3.6.24 because there are several plug-ins that I use that don't work in later versions, and I've been happily RoboForming with v. 6.10.2 for a loooong time. Obviously. this doesn't come under the qualification of FF8+, but I've been blocked nevertheless. New versiones of RoboForm DON'T work with FF 3.x, so now I've lost my ability to password all my banks and other sites I usually visit.

Would the genius that came up with this please fix the situation? I DO need to access my bank accounts, you know ...
Comment 125 Jon 2011-11-19 12:27:31 PST
I have to second what PAdam just wrote. I'm currently still using FF v3.6.17 with an older version of Roboform with no issues and was very surprised to get the addon blocked after reading the version #'s effected.

Can someone please unblock the Roboform addon for the older versions of FF?!
Comment 126 Jorge Villalobos [:jorgev] 2011-11-19 14:13:20 PST
I just verified that Firefox 8 downloads this blocklist entry:

> <emItem  blockID="i45" id="{22119944-ED35-4ab1-910B-E619EA06A115}">
>   <versionRange  minVersion="0.1" maxVersion="7.6.1">
>     <targetApplication  id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
>       <versionRange  minVersion="8.0a1" maxVersion="*" />
>     </targetApplication>
>   </versionRange>
> </emItem>

It looks like the version restriction is in place, but the last 2 comments indicate this is not correct. Can someone in QA please verify?
Comment 127 Jon 2011-11-19 15:42:29 PST
While I realize it's not the preferred way to run Firefox I ended up turning off the blocklist checking in about:config & as expected Roboform is working as should again.
I ended up updating FF to v3.6.24 & Roboform is still v6.10.1. Two reasons I didn't want to update FF or Roboform past these versions is that to go to Roboform v7 will cost money & going to FF v4 or higher breaks some of my extensions/addons (including needing Roboform v7).
If someone in charge of the blocklist corrects this I'll turn the blocklist checking back on but either way it was a good learning experience.

As an FYI, overall the blocklist must be working correctly because I have another machine with FF v7 & Roboform v7.5.2 and that one is still working correctly (per the versions it's suppose to effect).
Comment 128 Alex Keybl [:akeybl] 2011-11-20 09:00:59 PST
I just spent some time testing FF3.6.24 with RF6.10.0 (which reports an extension version in FF of 6.9.98).

I used the instructions at [1], since the error console command in [2] didn't seem to provide any feedback (or have an effect) when run on 3.6.24. Even using [1], it's not clear that the add-on blocklist was ever updated since app.update.lastUpdateTime.blocklist-background-update-timer didn't get set.

I instead edited the blocklist.xml file located in the profile directory and added the XML snippet from Comment #27. I did not see the RF toolbar disabled upon relaunch. QA verification will definitely help.


[1] https://wiki.mozilla.org/Extension_Blocklisting:Testing
[2] https://wiki.mozilla.org/Blocklisting/Testing#Testing_Staged_Blocklist
Comment 129 Mohamed Dabbagh 2011-11-20 18:10:19 PST
Tried to reproduce with Windows 7 x64 but with no luck. The following is what I tried:

Starting with FF 3.6.17
- Installed RF 6.9.95
  - Not compatible
- Tried RF 6.9.98, 6.10.0 (shown as 6.9.98), 7.1.1, 7.1.2 (both shown as 6.10.1) and 7.4.4 
  - All enabled properly
- Installed RF 7.5.2
  - Not compatible
- Uninstalled RF completely
- Installed RF 7.5.0
  - Not installed in FF
  - No dll/jar attached
  - Presumably not supported in this FF version but there was no mention of that during installation
- Upgraded to FF 3.6.24
  - Enabled properly
- Installed RF 6.9.98, 6.10.0 (shown as 6.9.98), 7.1.1 and 7.1.5
  - Enabled properly

Starting with FF 3.6.22
- Installed RF 6.9.0
  - Not compatible
- Installed RF 6.9.98
  - Enabled
- Installed RF 7.1.0 (shows as 6.10.1)
  - Enabled
- Uninstalled RF completely
  - RF 7.5.5
  - Not installed in FF
  - No dll/jar attache
- Uninstalled RF completely
- Installed RF 7.1.1, 7.1.3 (shows as 6.10.1) and 7.2.2
  - Enabled and got pop-up to update to 7.6.3
- Upgrade to FF 3.6.24
  - Extension enabled
- Tried RF 6.10.0 (shown as 6.9.98) then 7.1.0 (shown as 6.10.1)
 - Enabled properly

Starting with FF 3.6.24
- Installed RF 6.9.95
  - Not compatible
- Tried RF 6.10.0 (shown as 6.9.98), 7.1.0, 7.1.1, 7.1.2, 7.1.3 (all shown as 6.10.1), 7.2.2, 7.3.2, 7.4.0
  - All enabled
- Installed RF 7.5.0
  - Not compatible
- Upgraded to FF 7.0.1
  - RF enabled

Also tried other variations/combinations but still could not reproduce. Please provide more context or information to the setup and how/when the issue was experienced. For example, did you update Firefox and then experienced the issue? What exact version of Roboform were you using with which version of Firefox? What does it say for the extension in the add-ons manager? Did you have a certain version of Roboform, then updated and then you experienced the problem? We really appreciate any extra information we can get.
Comment 130 Jon 2011-11-20 19:50:07 PST
I've had RoboForm v6.10.1 on that particular machine for close to 2 years now. Had FF v3.6.17 on there for a while. When I went to use FF yesterday (11-19-11) there was a warning message to restart FF to due to Roboform not being compatible. Upon restarting FF Roboform was disabled & the toolbar was gone. After this I updated FF to v3.6.24 with RF still being disabled. 
As of now still if I leave the addons window open & toggle the blocklist checking enabled/disabled in about:config it states RF will be disabled/enabled.
Windows XP PRO sp3, 32bit OS

As I've stated earlier, if I just leave the blocklist disabled it works fine & I'm fine with that being I don't have that many extensions on that computer. Not sure why it can't be reproduced but as far as I'm concerned don't bother going crazy trying to fix it as I"m good with my fix for it.
Comment 131 juan becerra [:juanb] 2011-11-20 20:27:03 PST
PAdam, Jon, would you mind sending us the information corresponding to the Roboform extension that appears in the Extensions section in about:support?

I've tried installing version 6.10.2 by doing a google search that takes me to to a Softpedia site. When I install that and go to "About" in the taskbar Roboform icon, it does say that it is version 6.10.2, but the Firefox adapter is version 6.10.1. Other sites say that this version was released around March.

I tried editing the extension.update.interval and extension.blocklist.interval entries in about:config, and I've tried doing updates from 3.6.17 to 3.6.24, but it is only when I try updating to 8.0 through the major update offer that I get a warning about version incompatibility, and the older versions do get disabled after the jump.

I have not been able to reproduce the problem, yet.
Comment 132 Jorge Villalobos [:jorgev] 2011-11-20 23:03:25 PST
@PAdam and @Jon: it would also be useful if you can attach to this bug your blocklist.xml file from your profile directory. There's info on how to find your profile on this page: https://support.mozilla.com/kb/Profiles
Comment 133 PAdam 2011-11-21 03:28:31 PST
(In reply to juan becerra [:juanb] from comment #131)
> PAdam, Jon, would you mind sending us the information corresponding to the
> Roboform extension that appears in the Extensions section in about:support?

6.10.1, which corresponds to RoboForm 6.10.2
Comment 134 PAdam 2011-11-21 03:45:11 PST
(In reply to Mohamed Dabbagh from comment #129)
> Also tried other variations/combinations but still could not reproduce.
> Please provide more context or information to the setup and how/when the
> issue was experienced. For example, did you update Firefox and then
> experienced the issue? What exact version of Roboform were you using with
> which version of Firefox? What does it say for the extension in the add-ons
> manager? Did you have a certain version of Roboform, then updated and then
> you experienced the problem? We really appreciate any extra information we
> can get.

The issue appeared suddenly on Nov19. Firefox had updated itself to 3.6.24 a couple of weeks before that, but RoboForm continued to work properly. No updates to either FF or RF were done on Nov19 or immediate days before.

Firefox is 3.6.24, RoboForm is 6.10.2 (with FF interface 6.10.1)

The addons manager shows the extension as greyed-out and does not allow any access to it.

I tried upgrading RoboForm up to 7.4.2 (the last one that works with FF 3x) with no change to the blocking-out. While going back again, found that v7.2.5 allowed temporary 'attachment' to browser (via Task Bar icon), which made the RF Toolbar appear again. As per Jon's hint to disable the blocklist checking (#130, above), it enabled me to go back to RF v6.10.2 (7.2.5 did not work properly with some sites requiring the use of IE engine).
Comment 135 PAdam 2011-11-21 04:01:08 PST
Created attachment 575830 [details]
blocklist.xml as requested by Jorge Villalobos in #132
Comment 136 Jorge Villalobos [:jorgev] 2011-11-21 07:38:41 PST
(In reply to PAdam from comment #135)
> Created attachment 575830 [details]
> blocklist.xml as requested by Jorge Villalobos in #132

Thanks. The blocklist file has the correct entry, with the correct version range. For some reason Firefox is failing to understand it shouldn't block. Perhaps an add-on that makes it think it has a different version number?
Comment 137 PAdam 2011-11-21 08:08:19 PST
(In reply to Jorge Villalobos [:jorgev] from comment #136)
>For some reason Firefox is failing to understand it shouldn't block.
> Perhaps an add-on that makes it think it has a different version number?

(from InfoLister)

Last updated: Mon, 21 Nov 2011 16:02:34 GMT

User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.24) Gecko/20111103 Firefox/3.6.24 ( .NET CLR 3.5.30729; .NET4.0E)

*** Extensions (enabled: 18, disabled: 5; total: 23)
AboutPlug 1.5 
AI Roboform Toolbar for Firefox 6.10.1 
Bookmark This Page 0.3.2 [disabled]
DivX HiQ 2.1.1.94 
DivX Plus Web Player HTML5 <video> 2.1.1.94 
Edit Cookies 0.3.8.1 
Favicon Picker 3 0.5 
FireFTP 1.0.10 
IE Tab 1.5.20090525 [disabled]
IE Tab 2 (FF 3.6+) 3.10.7.2 [disabled]
IE Tab Plus 1.2.0.13 
IE View 1.4.5.2 [disabled]
InfoLister 0.10.3 
Java Console 6.0.24 
Java Console 6.0.26 
Java Quick Starter 1.0 
Link Pad 1.6.4 
Microsoft .NET Framework Assistant 1.3.1 
Print Preview Toolbar Button 0.1 [disabled]
Saved Password Editor 2.2.5 
SQLite Manager 0.6.8 
Tab Counter 1.8.8 
Tab Mix Plus 0.3.8.6 

*** Themes (3)
Default 
Simple Green [selected]
Unofficial Netstripe 

*** Plugins
Adobe Acrobat
BrowserPlus (from Yahoo!) v2.9.8
DivX VOD Helper Plug-in
DivX Web Player
getPlusPlus for Adobe 16263
Google Earth Plugin
Google Update
IE Tab Plug-in
Java Deployment Toolkit 6.0.260.3
Java(TM) Platform SE 6 U26
Microsoft Office 2003
Microsoft® DRM
Microsoft® Windows Media Player Firefox Plugin
Mozilla Default Plug-in
QuickTime Plug-in 7.6.9
RealJukebox NS Plugin
RealPlayer Version Plugin
RealPlayer(tm) G2 LiveConnect-Enabled Plug-In (32-bit) 
Shockwave Flash
Shockwave for Director
Silverlight Plug-In
VLC Multimedia Plug-in
Winamp Application Detector
Windows Genuine Advantage
Windows Media Player Plug-in Dynamic Link Library
Windows Presentation Foundation
Yahoo Application State Plugin
Yahoo! activeX Plug-in Bridge
Comment 138 Virgil Dicu [:virgil] [QA] 2011-11-21 08:16:12 PST
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0.1) Gecko/20100101 Firefox/8.0.1
Mozilla/5.0 (Windows NT 5.1; rv:8.0.1) Gecko/20100101 Firefox/8.0.1

Checked on the latest 8.0.1 build2 on Windows XP and 7 with Roboform 7.6.1, 7.6.2, 7.6.3 using the following steps: 
1. Install Firefox 7.0.1.
2. Install Roboform version.
3. Upgrade to 8.0.1 using a pave-over install.
4. Start Firefox with add-on enabled/disabled.

Firefox no longer crashes in any situation and Roboform is listed as enabled/disabled according to the option set in the Confirm Add-on screen. The only unexpected issue (also specified by Juan) is the error message received with 7.6.1, when Roboform is enabled after the upgrade an error message is displayed: "Could not initialize RoboForm add-on"
Comment 139 PAdam 2011-11-21 09:25:20 PST
(In reply to Jorge Villalobos [:jorgev] from comment #136)
> The blocklist file has the correct entry, with the correct version
> range. For some reason Firefox is failing to understand it shouldn't block.

Just to see what would happen, I toggled extensions.blocklist.enabled back to on and lo and behold, evrything is just working as it always has (at least regarding the RoboForm plugin).

I do notice, though, that the blocklist.xml file is dated 20Nov 11:00, which is after I started to experience problems and right in the middle when I was doing RF reinstallations and toggling on and off like crazy. Could it be that RF got blocked by an erroneus blocklist.xml sent out on 19Nov and corrected by the one that now sits in my 'puter?
Comment 140 Jorge Villalobos [:jorgev] 2011-11-21 10:29:54 PST
(In reply to PAdam from comment #139)
> Could it be that RF got blocked by an erroneus blocklist.xml sent out on
> 19Nov and corrected by the one that now sits in my 'puter?

It's possible. The blocklist tools are set up in a way that you first need to add the block and after that you set the application version limitation. It only took me a couple of minutes to finish the second step, so I didn't expect anyone to get the wrong blocklist during that window (due to caching and whatnot).

I could be that things can be done in a different order (it's the first block I've had to deal with), but we should fix those tools so that it all happens in a single transaction.
Comment 141 Justin Scott [:fligtar] 2011-11-21 12:27:51 PST
When adding a block that needs a specific app version range, I usually block the add-on with minVersion * and then add the version range and then go back and edit the * down to the actual version to make sure no one gets blocked incorrectly.
Comment 142 Jon 2011-11-21 14:19:47 PST
OK so I think this is the problem....

From blocklist

</emItem> -<emItem id="{22119944-ED35-4ab1-910B-E619EA06A115}" blockID="i45"> <versionRange maxVersion="7.6.1" minVersion="0.1"> </versionRange> </emItem>


From t/s info page (with blocklist enabled)....

AI Roboform Toolbar for Firefox
        6.10.1
        false
        {22119944-ED35-4ab1-910B-E619EA06A115}

My blocklist file is still from 11-19-11. Is there some way I can force it to update? I tried reinstalling FF v3.6.24 but that didn't do it. If I'm reading this correctly it's blocking all versions of RF under v7.6.2
Comment 143 Matthias Versen [:Matti] 2011-11-21 14:45:50 PST
Delete/renaming the file while Firefox isn't running should work.
Comment 144 Jon 2011-11-21 14:57:47 PST
I closed FF & made sure it wasn't running in the Task Manager, deleted the blocklist.xml & opened FF. FF runs but a new blocklist.xml didn't get created.
Comment 145 Jon 2011-11-22 13:49:30 PST
FF finally got a new blocklist this morning and RF is back to working as normal. Thanks for the help guys.
Comment 146 Donald Delozier 2011-11-23 15:37:50 PST
This may result in my no longer using Firefox as my browser.  I want the ability to override your block list.  I don't mind the occasional crash if I get the functionality Roboform provides.  What is my recourse here?
Comment 147 Alex Keybl [:akeybl] 2011-11-23 15:40:22 PST
(In reply to Donald Delozier from comment #146)
> This may result in my no longer using Firefox as my browser.  I want the
> ability to override your block list.  I don't mind the occasional crash if I
> get the functionality Roboform provides.  What is my recourse here?

Donald - What issue are you running into? What version of Firefox are you on? This block didn't prevent the occasional crash, but instead prevents a startup crash specifically on Firefox 8 that's reproducible on each launch.
Comment 148 Alex Keybl [:akeybl] 2011-11-23 15:41:44 PST
Forgot to mention that if your problem is that you find RoboForm is now disabled, you should upgrade to a RoboForm version later than 7.6.1.
Comment 149 Jon 2011-11-23 15:44:06 PST
If you already have v7 of RF you should be able to get the newest version for free. If something is stopping you from doing that you can try disabling the list like I mentioned in comment 127 or just stick with FF v7 as I believe this block should only effect FF v8 and above.
Comment 150 Donald Delozier 2011-11-23 16:17:49 PST
Thank you all for the quick responses.  Normal RoboForm update processes were not identifying the updates past 7.6.1 (which is where I was).  I have since manually installed the latest version 7.6.4 and it is back.  

I appreciate the help.  It was unclear that 7.6.1 was the only real troublesome version and RoboForm did not make it clear there was a later version when you select "Check for Updates".

I'm all set.
Comment 151 Virgil Dicu [:virgil] [QA] 2011-12-09 07:27:37 PST
Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20100101 Firefox/9.0 Beta 5 
Mozilla/5.0 (Windows NT 5.1; rv:10.0a2) Gecko/20111208 Firefox/10.0a2
Mozilla/5.0 (Windows NT 5.1; rv:11.0a1) Gecko/20111209 Firefox/11.0a1
Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20100101 Firefox/9.0 Beta 5
Mozilla/5.0 (Windows NT 6.1; rv:10.0a2) Gecko/20111206 Firefox/10.0a2
Mozilla/5.0 (Windows NT 6.1; rv:11.0a1) Gecko/20111209 Firefox/11.0a1

Verified on Firefox 9 Beta5, Firefox Aurora, Firefox Nightly on Windows XP and 7.
Used Roboform 7.6.1 (blacklisted) 7.6.2 and 7.6.6 (allowed).

The blacklisted version is disabled in F9 and Aurora-enabling it will return an error as stated in comment 138 and https://etherpad.mozilla.org/Roboform-Blocklist-Testing
While on nightly it is blacklisted without the possibility of enabling and with a notification leading to the blocklist roboform page.

Version higher than 7.6.1 work as normal, without any crashes occuring at start-up.
Comment 152 War59312 2011-12-22 08:45:48 PST
Still NOT working here. :(

Firefox 8 on Win7 x64 with Roboform 7.6.7

I get this:

roboform> zbx: Can not load RoboForm add-on
Please restart browser or reinstall RoboForm

Please restart browser

Incompatible module C:\Program Files (x86)\Pale Moon\extensions\{22119944-ED35-4ab1-910B-E619EA06A115}\rf-firefox.dll


Warning: WARN addons.manager: Exception calling callback: Please restart browser

Incompatible module C:\Program Files (x86)\Pale Moon\extensions\{22119944-ED35-4ab1-910B-E619EA06A115}\rf-firefox.dll
Comment 153 Mohamed Dabbagh 2011-12-22 09:59:19 PST
War59312, I tried with FF8 and Roboform 7.6.7 on Windows x64 and it was not blocked for me. Did you do an upgrade to either Firefox or Roboform lately? Can you try the steps in comment #144 (try this first) or comment #139 and see if it fixes your problem? Or try with a new Firefox profile and see if you notice the same issue. This way it can be known if it's an problem with your profile specifically. Thanks!
Comment 154 Jon 2011-12-22 14:57:10 PST
@War59312
Are you actually using Firefox or PaleMoon? Looking at the directories of your errors you're using PaleMoon. While I realize PaleMoon is basically Firefox are all of the extensions actually supposed to be compatible? I have PaleMoon on my computer also but just the portable version & haven't tried installing any extensions in it.
Also it appears as though it's not being blocked as this thread was originally about, it appears as though it's just not starting for some other reason.
Comment 155 War59312 2011-12-24 18:42:20 PST
Whoops yea I was trying it in both (normal firefox and pale moon), but I got it working.

I restarted windows and deleted all files in %temp% and now it works just fine. I had already tried deleting the block list with no luck.

Figures! Thanks guys! Confirmed fixed. :)

Note You need to log in before you can comment on or make changes to this bug.