Plugin name: npmozax.dll - Mozilla ActiveX control and plugin support
Plugin versions to block: 18.104.22.168 or lower
Applications, versions, and platforms affected: Firefox7.0.1+, Seamonkey2.4.1+ on Windows
Block severity: hard
How does this plugin appear in about:plugins?
Description: Mozilla ActiveX control and plugin support
Homepage and other references and contact info:
AFAIK: Adam Lock created this Plugin as part of his work at Netscape
>Note this project is no longer in active development. Content is made available for reference purposes only!
This is a very old Plugin that adds ActiveX Support to Mozilla and this Plugin will not work in any Firefox version higher as Firefox 1.5,
This Plugin will crash in Firefox7.0.1 and Seamonkey2.4.1
The crash reporter is triggered without any visible crash notification.
A simple page can trigger many crashes in the background and the pending folder of the crash Reporter will store gigabytes of pending crash reports !
That is the main reason for the hard block: The users hdd will get filled up with pending crash reports.
Johnath, does this block sound okay to you?
I missed this bugmail the first time around - sorry about that. The summary talks about a DLL, but comment 0 makes it sound like plugin blocklist.
I have no idea whether this thing is actually used in the wild for any legitimate purpose, cc'ng bsmedberg on the off chance that he does.
If it isn't, I certainly have no objection to either form of blocklisting.
This thing *was* used in the wild for legitimate purposes (Mozilla shipped it), but it has not been maintained in years and is pretty much guaranteed not to work in current builds. I think we are safe blocking it. If somebody were to resurrect a new version of this code/functionality, we can give it a different filename.
I have staged a block for this plugin: https://addons-dev.allizom.org/en-US/firefox/blocked/p89
It is hard-blocked for all platforms (the plugin only works on Windows, though) and all Firefox versions. If we care about 1.5 users who may still use this (did we even have a blocklist back then?), I can limit the version range.
Following the release of Firefox 13 we had a fair number of support requests in the Italian support forum with users unable to play Flash content. And we found that this plugin is the "culprit".
Even in the US forum there are similar threads:
Jorge: Can we push the block to production ?
Anthony, can you test the staged block?
(In reply to Jorge Villalobos [:jorgev] from comment #8)
> Anthony, can you test the staged block?
Mid-aired and forgot to CC Anthony.
I have no idea how to install this plugin to test the stage. Can someone please help me? The instructions on the website do not seem to work.
Andrew, can you give this a try?
The website on comment #0 offers the plugin packaged in an XPI file with isn't compatible with any recent version of Firefox. This means users who have this plugin installed got it in a different way that installed it as a standalone plugin. Since manually installing plugins is a convoluted process involving touching the Windows Registry, I think it's best just to push this block to prod and gauge user reaction.
So, the block is now in place:
Matti, please follow up with users next week so we can make sure the block is working correctly.
Yeah, there were manual instructions on the website which I was trying to follow but it didn't seem to be working for me.
FWIW, I do confirm that the block appears in my blocklist.xml file.
The easiest way to install it now is to download the xpi, rename it to zip, extract the npmozax.dll and put the file in c:\program files\Mozilla Firefox\plugins\.
That is enough to let it appear in about:plugins.
I triggered a blocklist reload and I can confirm that the block is working.
Does this block include Seamonkey ?
This would make sense because this is a NPAPI Plugin and not an extension and is therefore not app specific.
The block should work on any application that uses the same blocklist. I don't know if SM has one, but if it does, I assume this block will also apply.
Seamonkey has the same blocklist but the blocklist server delivered different entries based on the OS and the app in the past. It seems that this changed as i have all the Firefox extensions in my Seamonkey blocklist.
(In reply to Jorge Villalobos [:jorgev] from comment #12)
> The website on comment #0 offers the plugin packaged in an XPI file with
> isn't compatible with any recent version of Firefox. This means users who
> have this plugin installed got it in a different way that installed it as a
> standalone plugin. Since manually installing plugins is a convoluted process
> involving touching the Windows Registry, I think it's best just to push this
> block to prod and gauge user reaction.
Just for information: I had this plugin blocked today, but it is nothing I have ever installed manually. I have been running an older version of Firefox for a long time, and it most likely got installed then, when some website, game or whatever needed the plugin to be able to run. The XPI format (whatever that is) must be compatible with the older versions of Firefox, and the plugin must have been installed automatically, because I have certainly not edited any registry entires to get this plugin.
This plugin came preinstalled with Netscape6/7 to support ActiveX in the browser.
At that time IE had a market share of 90% and many websites used ActiveX technology.
Due to the success of Firefox this is now history.
XPI stands for "Cross Platform install" and is special zip file that contains extensions for Mozilla Products. The format changed over time (install.js vs install.rdf ) and this XPI worked in previous version (up to Firefox 3.6?).
I just checked Firefox's folder containing crash reports, and I have 8,500 files using up 84MB of disk space. I assume they were all created by this plugin as they have been comming daily until june 7th when the plugin was blocked.
Couldn't you possibly clean out all these files in the process where you block the plugin, or at least tell people that they might have a lot files that need to be deleted manually? I only found out about the report files because I began reading more about the plugin, and I bet they will go unnoticed by most people. I never even knew about a folder with crash reports before I read about it in here.
@akeybl: could we use the Hotfix add-on to do a one-time cleanup?
bug 690841 should remove those pending reports if it get fixed someday...
(In reply to Jorge Villalobos [:jorgev] from comment #20)
> @akeybl: could we use the Hotfix add-on to do a one-time cleanup?
I'd rather take the in-product fix in bug 690841 instead of coming up with a well qualified one-off. I don't think this issue is critical enough to warrant an add-on hotfix, or escalation of bug 690841. My opinion would be different if the crash reports took up significantly more space, or this somehow caused performance issue.