The return of .NET Framework Assistant · 2009-08-10 11:34 by Wladimir Palant
Do you remember the commotion about Microsoft silently installing its .NET Framework Assistant extension through Windows Update? And how everybody was upset about this being forced down their throats, even without an “Uninstall” button in the add-ons window? And how Microsoft fixed at least the "Uninstall" button? And how that fix broke Adblock Plus and NoScript temporarily, causing tons of complains for both extensions? Well, the show isn’t over yet, lean back and watch.
I was getting occasional complaints from people claiming that Adblock Plus broke Firefox user interface — with Adblock Plus installed they would get empty spaces in the Tools menu and in the context menu, and there would be an “empty resizable frame” at the bottom of the Firefox that would just not go away. While it was obvious what happened here (one of two Adblock Plus overlays failed to apply) I had a very hard time figuring out why. The issue was similar to the one mentioned above that people were experiencing with the .NET Framework Assistant extension — except that this extension wasn’t installed. In fact, some people went as far as to create a new Firefox profile with Adblock Plus being the only extension. And the problem still wouldn’t go away.
Being tired of guessing I asked a user to give me remote access to his computer. He agreed and after some experimentation I could exclude malware and malfunctioning security software as the cause. I also didn’t discover any unusual preferences or the like. Then I had a look at the extension registration files in his Firefox profile directory. And one entry caught my attention: .NET Framework Assistant.
So, why is .NET Framework Assistant listed in the extension registry when supposedly it isn’t installed? Well, because it is installed, at least somewhat. Here is how Microsoft’s “fix” for the uninstall problem above works: the .NET framework installs a global Firefox extension as it did before. However, now it is only a minimal “bootstrap” extension meant to install the “real” .NET Framework Assistant in user’s profile. Once that is done the extension in profile takes precedence and the “bootstrap” extension is no longer active. However, if the user chooses to uninstall the .NET Framework Assistant extension the “bootstrap” extension becomes active again. So, wouldn’t users be confused if they uninstall one .NET Framework Assistant and notice another one pop up instead that they can no longer uninstall? They sure would be. But Microsoft found a very “elegant” solution for this problem — they simply marked the “bootstrap” extension as hidden so that it would no longer show up in the list of add-ons.
The problem was actually being caused by that extension. And due to the fact that it wouldn’t show up in the list it was also very hard to find the cause. Not to mention that marking the extension as hidden made it impossible to disable the globally installed extension — an option that the original version of the extension did offer. Well done addressing concerns! On the bright side, I was able to include a workaround in the current Adblock Plus development build that cures the problems (this is also going to be included in Adblock Plus 1.1.1, to be released very soon).
The technical details, if you are interested: the “bootstrap” extension defines a browser overlay in its chrome.manifest file. However, on that particular machine its chrome directory was empty, no UI files whatsoever (I guess they were there originally but were removed after installation of the “real” extension to make sure it is not installed again). So Firefox tries to apply an overlay and fails because the file doesn’t exist. This makes Firefox cranky enough that it doesn’t apply other outstanding overlays (is there a bug on that? need to check). The workaround was to override the overlay URL with a data: URL, that way the overlay exists and Firefox is happy.
Commenting is closed for this article.