Closed Bug 382356 Opened 18 years ago Closed 16 years ago

Trunk topcrash on startup [@ MultiByteToWideChar] [@ kernel32.dll + 0x9dea] involving Internet Download Manager

Categories

(Toolkit :: Blocklist Policy Requests, defect, P5)

Product:
Toolkit
Component:
Blocklist Policy Requests
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: ispiked, Unassigned, NeedInfo)

References

Details

(Keywords: qawanted, topcrash, Whiteboard: [see comment #107 before posting])

Crash Data

Attachments

(2 files, 6 obsolete files)

v2, fixed app range and extension range
451 bytes, text/xml
Details
IDM
2.54 KB, application/xml
Details
The following crash is showing up as the #1 topcrash on both Breakpad and Talkback's topcrash reports: Incident ID: 32571243 Stack Signature kernel32.dll + 0x9dea (0x7c809dea) 13a7bc7e Product ID FirefoxTrunk Build ID 2007052704 Trigger Time 2007-05-27 14:29:43.0 Platform Win32 Operating System Windows NT 5.1 build 2600 Module kernel32.dll + (00009dea) URL visited User Comments Since Last Crash 7 sec Total Uptime 548 sec Trigger Reason Access violation Source File, Line No. N/A Stack Trace kernel32.dll + 0x9dea (0x7c809dea) pr_LoadLibraryByPathname [mozilla/nsprpub/pr/src/linking/prlink.c, line 836] Here's the Breakpad stack: 0 kernel32.dll@0x9dea 1 pr_LoadLibraryByPathname 2 nsCOMPtr_base::~nsCOMPtr_base() 3 nsDirectoryService::Get(char const *,nsID const &,void * *) Talkback reports that there are at least ~20 unique users that are hitting this crash. It's highly likely that this crash is caused by Internet Download Manager, as idmmzcc.dll is loaded in most all of the crash reports.
I sent an email to info@tonec.com which was listed on the front page of http://www.internetdownloadmanager.com/ explaining the problem and linking them to a crash report as well as here.
This crash started appearing in Talkback in 2007-05-21-08 builds. Those builds have the patch for bug 377437 in them, and judging from the similar #2 topcrash, it would seem that the extension is using frozen string APIs which may be causing the crash.
Severity: normal → critical
I'd like to know (from them, I guess) which version of the SDK they're linking against, and whether updating to at least a 1.7 SDK (but preferably 1.8) would be reasonable. Is this a common piece of software? I've never heard of it.
fwiw, kernel32!MultiByteToWideChar = 0x7c809bf8 so the stack trace into windows is correct. kinda disappointing that breakpad didn't figure that out. bsmedberg: shouldn't it be possible for us to figure that out by looking at their library?
yes... you'll see the #2 topcrash is "MultiByteToWideChar"... so we don't have symbol info for whatever version of kernel32 that is.
timeless: it would have, if we had symbols for it at the time. I uploaded symbols for Windows XP SP2, but kernel32.dll probably got updated multiple times via security patches. I uploaded symbols for that version to our server the other day, so we should get better reports now.
Summary: Trunk topcrash on startup [@ kernel32.dll + 0x9dea] involving Internet Download Manager → Trunk topcrash on startup [@ MultiByteToWideChar] [@ kernel32.dll + 0x9dea] involving Internet Download Manager
It's the #1 topcrash now.
(In reply to comment #8) > It's the #1 topcrash now. We can't do much about it since it's third party software though, right?
Well, we could sanitize input to pr_LoadLibraryByPathname
Or we could try to blacklist the unfixed versions of internet download manager... does anyone know what mechanism it uses to hook Firefox? (extension, plugin, DLL hooking magic)
(In reply to comment #3) > I'd like to know (from them, I guess) which version of the SDK they're linking > against, and whether updating to at least a 1.7 SDK (but preferably 1.8) would > be reasonable. They claim on their website that they support Mozilla Firebird, which was 1.6 I think(?). We might have better luck in contacting them via support@internetdownloadmanager.com.
int wlen = MultiByteToWideChar(CP_ACP, 0, name, -1, NULL, 0); According to MSDN http://msdn2.microsoft.com/en-us/library/ms776413.aspx cbMultiByte can be set to -1 if lpMultiByteStr ('name') is null-terminated if 'name' here is not null-terminated, it might read outside the valid memory for the 'name' pointer causing the OS to terminate the application.
Nominating for blocking1.9 in case there is something that can be done. So hopefully this can get on the radar and more traction.
Flags: blocking1.9?
+'ing this but making it a P5. Anyone care to help here?
Flags: blocking1.9? → blocking1.9+
Priority: -- → P5
Where "help" means "Contact them via email?"
(In reply to comment #11) > Or we could try to blacklist the unfixed versions of internet download > manager... does anyone know what mechanism it uses to hook Firefox? (extension, > plugin, DLL hooking magic) > From the FAQ it appears to be a plugin: If it doesn't help, please check that NPIDMan1.dll and NPIDMan2.dll files exist in Plugins subfolder of Mozilla root folder. If these files do not exist, please download them from the links above and place them to the browser Plugins folder. http://www.internetdownloadmanager.com/faq.html
Sent an email to the email address above referencing this bug.
Keywords: qawanted
We may be able to use the plugin blocklisting from bug 391633 to disable the offending plugins... it would be good to figure out which versions are broken so that we don't blocklist more than we have to. I heard that IDM released a version that works with Minefield, but that's rumor not fact.
This problem has been fixed in July of 2007. Please try to use the latest version of IDM Mozilla extension. The problem first occurred when FireFox development team changed several interfaces supposed to be frozen. Also we needed to recompile the extension with a new Mozilla SDK. The problem may still persist in one case only. If a user launched idmmzcc.xpi installation file for old versions of IDM from FireFox manually. Since FireFox 1.5 it is possible to add extensions using Windows Registry with a specified path for dll. IDM changes this default dll during IDM updates. Although new versions of IDM add FireFox extension using registry, it does not replace old dll in Firefox user profiles. If FireFox 3.0 could use registry settings for extensions at first and then use the settings in user profiles the problem would not persist. The user won't need to change anything manually after installing a new version of IDM. Now users have to delete old dll manually to start Firefox and then install a new idmmzcc.xpi extension which doesn't cause this problem anymore. Charles Jones Software engineer Tonec Inc. 641 Lexington Avenue, 15th fl. New York, NY, 10022
Charles, that's great information... what are the extension ID and version number of the broken extension version(s)? We can use that information to blacklist the bad version to avoid crashes.
Benjamin, we have the same extension ID for bad and good versions of IDM Mozilla extension. Only the version number differs. How does the blacklist work? We have concerns that many IDM users may lose IDM Mozilla integration after the next Firefox update. Firefox should find and run the new IDM extension listed in Firefox settings in registry while blocking the old extension in user profiles.
The blacklist can blacklist particular versions and (I think) version ranges. We definitely do not want to disable IDM integration in the case where it works correctly.
Specific extension versions and version ranges can be blocklisted along with specific app versions and version ranges. cc'ing morgamic since he maintains the blocklist
We have checked all our distributives with FireFox 3.0b2 from 16 of November. Problems occur with the following extensions: Extension ID: "mozilla_cc@internetdownloadmanager.com" Version numbers: 2.1 3.1 3.2 3.3 Please notify us on support@internetdownloadmanager.com email address or here at forum when you release a version in which these extensions are blocked. We will test the situation described above. Best regards, Dave Saeger IDM Support Tonec Inc.
Reassigning to morgamic for blocklisting.
Assignee: nobody → morgamic
To be more specific: we should blocklist the above ID/version pairs for Minefield/Firefox 3 only (version >= 3.0a1) and it would be very helpful to do it ASAP so we don't screw over beta1 users.
Attached file v1, blocked for all Fx (obsolete) —
This would be the potential XML -- is this what we want? It blocks the extension for all versions of Firefox. Seems we should add an application range, in which case I'd need a min and max version for the lower and upper bounds.
Attachment #289347 - Flags: review?
No - we only want to block it for Firefox 3 and forward. Only 3.0a1 and greater to be more specific.
Added ranges here -- Is there a designated way to add a wildcard to the upper bound in max? Currently there is *.
Attachment #289347 - Attachment is obsolete: true
Attachment #289347 - Flags: review?
A * should work
(In reply to comment #30) > Created an attachment (id=289349) [details] > v2, fixed app range and extension range > > Added ranges here -- Is there a designated way to add a wildcard to the upper > bound in max? Currently there is *. Looks good, * does indeed mean up to an unlimited version. You can even leave off the maxVersion and it would default to that.
Would prefer to use * otherwise I'd have to change the script. It looks for non-null version pairs when dealing with ranges. As far as testing, I drew this up: http://wiki.mozilla.org/Extension_Blocklisting:Testing If we're okay with the proposed XML I can get QA on board and see what their schedule looks like.
(In reply to comment #33) > Would prefer to use * otherwise I'd have to change the script. It looks for > non-null version pairs when dealing with ranges. Yeah I didn't mind which, was just mentioning it in passing.
The xml looks fine.
> The problem first occurred when FireFox development team changed several > interfaces supposed to be frozen. Charles, which ones?
Charles, could we get copies of the older versions so we can QA this ASAP?
Yea - this is showing up as the #1 topcrash for beta (6x more than #2) - so it would be great to get this wrapped up...
I emailed IDM support directly to see if we can get a response today.
(In reply to comment #37) > Charles, could we get copies of the older versions so we can QA this ASAP? Charles is on vacation till the end of November. The old version of IDM can be downloaded here: http://www.internetdownloadmanager.com/tmp/Nov-22-2007/idman509.exe Or in order to reproduce a crash you can install just the extension without installing IDM. Here is the version 3.3 of the extension: http://www.internetdownloadmanager.com/tmp/Nov-22-2007/idmmzcc.xpi It is even better to run idmmzcc.xpi in order to install the old extension. Because if after this you will update IDM to the latest version, the problem will remain. (In reply to comment #36) > > The problem first occurred when FireFox development team changed several > > interfaces supposed to be frozen. > Charles, which ones? I am not sure about interfaces. Problems were with nsEmbedCString. We compiled our DLL with FROZEN gecko-sdk 1.4. At first Minefield did not crash. The version 3.0a1 worked perfectly with our old extension. This why, we included version 3 for FireFox in our install.rdf. Then when after some version of Minefield it started to crash, we compiled THE VERY SAME source code of our DLL with gecko-sdk 1.7. It stared to work with Minefield but versions 1.5 and 2.0 of FireFox started to crash. The problem was solved rather simply: in our DLL we used global variables of nsEmbedCString type and when extension addressed them FireFox crashed. We added our class MyStrClass with the same methods and changed type from nsEmbedCString to MyStrClass for all global variables. After this extension complied with any sdk version works perfectly with all versions of Firefox and Minefield.
I was able to verify that blocklisting works, and updated the test plan wiki I linked to earlier. Could we get another set of eyes on this to help test assertions listed in the wiki? Here's the updated wiki with testing instructions: http://wiki.mozilla.org/Extension_Blocklisting:Testing If all looks well, we can get 2.1->3.3 blocklisted for 3.0a1+ immediately.
Status: NEW → ASSIGNED
Stephen and I have worked on this for both XP and Vista and have been unable to get them to pull and update the local blocklist.xml. Even when explicitly setting a local blocklist.xml (the attached one) Firefox still crashes on startup. Has anybody been able to verify that blocklisting works on Vista?
Note: as per face to face discussion with morgamic today the XRE startup code is responsible for not loading extensions after they are disabled and it is entirely possible that the startup code loads the extension once before disabling it which could cause this to occur.
rob, can you file a separate bug for that? I think we have a case where, on upgrade, we're reading the "old" extensions.ini from the profile... we'll need to come up with a reasonable heuristic for removing/ignoring this file in some set of circumstances.
What do we want to do regarding the service? Should I still publish the blocklist XML? I was able to verify the test cases in the wiki for another extension.
Benjamin, I have just tested Firefox 3 beta 2 and Minefield 3 beta 3pre with an old version of IDM extension and they both crashed. Have you been able to block the incompatible versions of IDM extension? Let me know if we can do anything on our part before holidays. Thanks.
Morgamic, assuming the blocklist has been QAed with Firefox 2, yes please push it.
http://www.mozilla.com/blocklist/ needs to be updated with text concerning this.
Yea, was already working on that.
So should this be closed?
Yep. This is resolved. Extension is blacklisted and site updated.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
We can't verify this in-client until bug 406118 is fixed; setting dependency.
Depends on: 406118
(In reply to comment #56) > It's still a top crasher #3 at the moment with latest nightly builds: > > http://crash-stats.mozilla.com/report/list?range_unit=weeks&version=Firefox%3A3.0b3pre&range_value=2&signature=MultiByteToWideChar As it will no doubt continue to be, until bug 406118 is fixed.
looks like bug 406118 was fixed as part of beta 4, but the MultiByteToWideChar still shows as the #4 top crash. anyone have any ideas?... same stack sig from another source? stuff not working right with the blocking?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Stack looks a bit different. Here the top 10 frames of bp-01aea2ca-f02b-11dc-8839-001a4bd43ed6: 0 MultiByteToWideChar 1 pr_LoadLibraryByPathname mozilla/nsprpub/pr/src/linking/prlink.c:842 2 PR_LoadLibraryWithFlags mozilla/nsprpub/pr/src/linking/prlink.c:580 3 idmmzcc.dll@0xcb01 4 idmmzcc.dll@0xd423 5 idmmzcc.dll@0xd587 6 nsFactoryEntry::GetFactory(nsIFactory**) mozilla/xpcom/components/nsComponentManager.cpp:3559 7 nsComponentManagerImpl::CreateInstanceByContractID(char const*, nsISupports*, nsID const&, void**) mozilla/xpcom/components/nsComponentManager.cpp:1751 8 nsComponentManagerImpl::GetServiceByContractID(char const*, nsID const&, void**) mozilla/xpcom/components/nsComponentManager.cpp:2189 9 nsCOMPtr_base::assign_from_gs_contractid_with_error(nsGetServiceByContractIDWithError const&, nsID const&) nsCOMPtr.cpp:141 10 NS_CreateServicesFromCategory(char const*, nsISupports*, char const*) mozilla/xpcom/components/nsCategoryManager.cpp:900 Sadly the comment field is used really sparely.
We only blocklisted a certain set of IDM. I heard someone the other day suggested that the newer version was also having problems though I haven't checked that for myself. This could also be caused by the way we currently distribute the blocklist. Currently it can take up to a day after you first run Firefox before the blocklist is downloaded and active. If for instance the user has not used Firefox in a while and an older version of IDM is still on the system then they will be vulnerable to crashing when they first try b4. I already have bug 420356 filed on closing down this window of vulnerability.
I was poking around, and I noticed that IDM claims compatability with Firefox maxVersion 3.9. Definitely bogus.
As we said above, the old version of IDM extension with a bug resulted in crash in MultiByteToWideChar had maxVersion set to 2.9. We tested the old extension with early 3.0x releases of Firefox like 3.0a1 and 3.0a2 and it worked well. Since we use frozen interface and to avoid frequent extension update for our users, we raised maxVersion to 3.9. Note that the problem with strings appeared after some 3.0x Firefox update, thus even if we set maxVersion to 3.0, the bug would appear anyway. We have fixed the bug in July 2007, and all Firefox 3.0x releases including 3.0b4 work well with this new dll. Today we have tested Firefox 3.0b4 and 3.0b5pre with old version of idmmzcc, and it still runs and crashes the Firefox. Thus blocklisting of old extension does not seem to work. If you can fix the blocklisting, it should resolve the problem. Or maybe you can include an update process for old versions of idmmzcc to your Firefox installer to update old idmzzcc to its new version? Charles Jones Software engineer Tonec Inc. 641 Lexington Avenue, 15th fl. New York, NY, 10022
the blocklist apparently takes a day before it is downloaded. can you create a new profile and leave it open for a day before trying to install a bad version? :)
Charles, a couple of quick comments and questions... > Note that the problem with strings appeared after some 3.0x Firefox update, thus even if we set maxVersion to 3.0, the bug would appear anyway. the idea we are promoting is that if you would have set max version to 3.0b1 then very few users would be currently affected by this since most have migrated up to 3.0b4 at this point. Not advancing the maxVersion until the release and a bit of testing happens keeps us from having to block due to any kind of security or stability problem. Does that make sense? > We have fixed the bug in July 2007, and all Firefox 3.0x releases including 3.0b4 work well with this new dll Can you provide more detail on which versions of IDM you tested? Looks like we are only blocking up to IDM 3.3 if I read this right... <emItem id="mozilla_cc@internetdownloadmanager.com"> <versionRange minVersion="2.1" maxVersion="3.3"> The crashes I'm still seeing on incoming reports at http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&range_unit=weeks&version=Firefox%3A3.0b4&signature=MultiByteToWideChar&range_value=1 are in large part on idmmzcc.dll 4.0.0.1 (here is an example http://crash-stats.mozilla.com/report/index/d1550640-f0c3-11dc-8dbd-001a4bd43ef6 ) It looks to me like we need to advance the blocking to this version, or look at providing another fix to that version if its available. Does this seem accurate?
or maybe we just need a roadmap that correlates IDM product version numbers to dmmzcc.dll version numbers to make sure we are effectively blocking, and a chance for the blocking to fully kick in.
> Since we use frozen interface and to avoid frequent extension update for our > users, we raised maxVersion to 3.9. Note that the problem with strings appeared That's a very bad thing to do. There is no guarantee that a Firefox 3.5 wouldn't be released on Mozilla 2 which *can* break binary compatibility. You should only be specifying a maxversion of something you've tested...
We shouldn't allow the client to accept such future version compatibility claims. If an add-on claims to be compatible with major or even minor versions that haven't shipped yet, we should just deny installation.
If that's official policy, then why the hell do we bother making any claims of compatibility/frozen interfaces?
Besides which, you can't implement that rule because it would require looking into the future, which we haven't mastered yet: If we've already release 3.0b4 and a user tries to install the extension into FF2.0.0.12, how do we know whether the future version exists yet?
It wouldn't be out of the question to include such information in the blocklist
Christian, our add-on compat isn't a promise never to break. It's a promise to not break with security and stability updates. I'm pretty sure we're cool with breaking add-ons from major version to major version (2.0 to 3.0) and even minor version to minor version (3.0 to 3.1), though as i said, not for security and stability releases (ex. 2.0.n to 2.0.n+1). If we're cool with breaking add-ons them from version to version, I don't see why we wouldn't prevent the client from accepting a compat statement for future versions. If we can't be predictive across the board, as bsmedberg says, then let's at least try to do it for known offenders.
Asa - he's referring to compile time binary compatibility, which we've said we'll support until we move to moz2.
So we give less of a promise to our preferred method of add-ons development (xp js extensions) than we do to the minority case of compiled add-ons. Wow. Sounds like a broken system to me.
There's also plugins and xulrunner consumers. Note that there is talk of changing all of this once we hit mozilla2.
We noticed that the Firefox seemed to block the broken version of extension now and run without crashes. It would be great if Firefox could update installed extensions when it updates itself to newer versions. We tested a condition when a user have installed a new Firefox with an old(broken) version of IDM MZCC extension. Users can only uninstall the broken extension in "Add-ons" Firefox menu. If you install the latest version of IDM MZCC extension manually, then everything will be working fine, but most users don’t know it. "Find updates" button in Firefox Add-on menu does not work for IDMMZCC. We set the max version to 3.0pre and submitted new IDMMZCC extension to https://addons.mozilla.org/en-US/firefox/addon/6973. How can we make the button working and how can Firefox update the extension automatically if it finds a compatible update?
(In reply to comment #76) > We noticed that the Firefox seemed to block the broken version of extension now > and run without crashes. It would be great if Firefox could update installed > extensions when it updates itself to newer versions. If the extension were not marked compatible with the new version then it does do a full update check and offer to install updates on the first startup > We tested a condition when > a user have installed a new Firefox with an old(broken) version of IDM MZCC > extension. Users can only uninstall the broken extension in "Add-ons" Firefox > menu. If you install the latest version of IDM MZCC extension manually, then > everything will be working fine, but most users don’t know it. "Find updates" > button in Firefox Add-on menu does not work for IDMMZCC. As I recall you install your extension via the windows registry? The application does not check for and install updates for extensions installed like this, they are considered to be third party provided extensions that should be updated by the providing application. If this is not the case then please file a new bug and copy me in and I'll do some further investigation. Given that this crash has really dropped (down to 36th for 3.0b5) I'm going to close this as fixed. The crash is still there because it is still possible for an old blocklist to be used. This happens for a user who used Firefox 2 before the extension was added to the blocklist, then didn't use it again and then installed Firefox 3 to test. In this case they would have an old blocklist in their profile.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
Attached file firefox.exe (obsolete) —
In very early fx3 release data I'm seeing this crash show up again with comments like: ok tried several times now to open after the upgrade and now i dont have an internet browser... thanks, please fix soon!!! Everytime ! module list from one report http://crash-stats.mozilla.com/report/index/00000d94-3cbe-11dd-a8e6-001cc45a2c28 shows idmmzcc.dll 4.0.0.2 do we need to bump the blocking max version higher? not all the module lists indicate Internet download manager. here are other some of the other .dll's to checkout from a few of the reports I've gone though. none have version info. ColorZilla.dll RocketDock.dll nsIGetter.dll full list to analyze is at http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&range_unit=hours&version=Firefox%3A3.0&signature=MultiByteToWideChar&range_value=6
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
So the new versions of the IDM are also having same things?
the details in crash report http://crash-stats.mozilla.com/report/index/00000d94-3cbe-11dd-a8e6-001cc45a2c28 makes it look that way, unless something else is going on.
Hi idmmzcc.dll v4.0.0.2 is an old dll version. The version of idmmzcc.dll and the version of xpi extension (one that is specified in install.rdf) DOES NOT HAVE TO MATCH for our extension. This dll version corresponds to version 3.3 of XPI that should be blacklisted. It's strange that our extension was not updated automatically for these users and blacklisting did not work as well. Also notice that the majority of reports don't show our dll. Charles Jones Software engineer Tonec Inc. 641 Lexington Avenue, 15th fl. New York, NY, 10022
Flags: blocking1.9.0.1?
This is topcrash #40; doesn't block any particular branch release as the solution (per comment 82) is to blocklist v3.3 of the Internet Download Manager --> mozilla.org::Blocklisting
Assignee: morgamic → nobody
Status: REOPENED → NEW
Component: General → Blocklisting
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.1?
Flags: blocking1.9.0.1-
Flags: blocking1.9+
Product: Core → addons.mozilla.org
QA Contact: general → blocklisting
Version: Trunk → unspecified
(In reply to comment #83) > This is topcrash #40; doesn't block any particular branch release as the > solution (per comment 82) is to blocklist v3.3 of the Internet Download Manager That version is already blocklisted
ive never ask to anybody to look after my IDM software on firefox. what a hell !! how stop this #### thing ?????????
Status: NEW → RESOLVED
Closed: 17 years ago → 16 years ago
Resolution: --- → WORKSFORME
aq bingung
IDM CC 3.3 is being blocklisted........Can anybody suggest what is the solution to this?
IDM CC 3.3 is being blocklisted... As someone have the solution to resolve this problem and how to modify or add a new extension to working well with my official idm ?
I bought IDM to use with specifically with Firefox. I do not or never had a problem with the add on. Please do not babysit for me. You have rendered my IDM useless for how I use it. Reinstate the add on. There is an option to disable it, if people are having a problem then use the disable option, that is what it's for.
Flags: blocking1.9.0.1-
reta_1999@yahoo.com: Please don't remove any declined flags from bugs. Thanks.
Hi frnds....a new version of idmcc has been released (IDMCC 5.6) and it works fine with my updated firefox 3.0.1. I hope this information can help you.
To all IDM users: The problem has been fixed a long time ago. All you need to do is to update old IDM CC extension. Please read our IDM integration guide for Firefox and other Mozilla based browsers: http://www.internetdownloadmanager.com/support/firefox_integration.html Hope it helps Charles Jones Software engineer Tonec Inc. 641 Lexington Avenue, 15th fl. New York, NY, 10022
Flags: blocking-firefox3.1?
This bug is closed, it doesn't make sense to request blocking on it.
Flags: blocking-firefox3.1?
Flags: blocking1.9.0.5?
Flags: blocking1.9.0.4?
Flags: blocking1.8.1.19?
Flags: blocking1.8.1.18?
Flags: blocking-firefox3.1?
Attachment #324723 - Attachment description: <blocklist> − <emItems> − <emItem id="mozilla_cc@internetdownloadmanager.com"> − <versionRange minVersion="2.1" maxVersion="3.3"> − <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}"> <ver → firefox.exe
Please don't meddle with flags when you clearly don't know what you are doing.
Flags: blocking1.9.0.5?
Flags: blocking1.9.0.4?
Flags: blocking1.8.1.19?
Flags: blocking1.8.1.18?
Flags: blocking-firefox3.1?
Attachment #324723 - Attachment is obsolete: true
Attachment #324723 - Attachment is patch: false
Attachment #324723 - Attachment mime type: text/plain → application/octet-stream
Crash reporter lists 2567 crash reports with the same stack and the module idmmzcc.dll in version v4.0.0.1, e.g. bp-36ef08f8-a3dd-11dd-82db-001a4bd43ed6 The full list can be seen here: http://crash-stats.mozilla.com/?do_query=1&product=Firefox&platform=windows&query_search=signature&query_type=contains&query=MultiByteToWideChar&date=&range_value=1&range_unit=months Is the IDM in version 4 not blocklisted?
Flags: wanted1.9.0.x+
Please enable me internet download manager.
um i think you all need to go to school for computers i think u are a bunch of idiots first off i have been using idm with fire fox for as long as they have they have been compatible and i have never had a problem so ya alls just need to learn a little more about computers i suggest that u make sure u install it correctly after installing it close firefox and restart ur computer run imd and then restart ur computer again then ur all set u retards
Flags: blocking1.9.0.19?
Flags: blocking1.9.0.19?
Can not complete IDM download file
Please provide me with a workaround to work with the IDM plug-in as you guys provide us with the link on your website https://addons.mozilla.org/en-US/firefox/addon/6973/eula/76836?src=addondetail to download the IDM plug-in which fails to install giving reference to this bug. I have bough IDM and I am not able to use it because of your silly interpretation. I have never seen My Firefox crash. Please suggest how we can work together on this else i will be forced to look for legal channels.
What bug? Firefox hasn't crashed on me yet. IDM hasn't given me any problems either. Can you tell me what we should do considering we've invested money on this great product? This really sucks!
WTF? The only reason I haven't abandoned this browser in favor of Chrome before is because the IDM integration works, and now Mozilla is blocking it? If this hasn't been resolved in 24 hrs, guess I'll be dumping Firefox. Doesn't ANYBODY have a workaround? This whole blocklist thing seems kind of fascist to me. I don't mind a nice warning that it's unstable (which it is not for me), but to simply block it is ****.
There is no issue with this add-on. It has worked perfectly for me for years. Furthermore, not allowing users the option of enabling an "incompatible" add-on is ****-poor programming and smacks of proprietary design. Reminds me a lot of Microsoft, welcome to the club...I guess.
http://www.internetdownloadmanager.com/support/firefox_integration.html covers how to get the proper version of IDM running in Firefox. If you're being pointed at this bug because the addon is blocked, you're running a version between 2.1 and 3.3... and the current is 6.9.1, so you're likely very very out of date.
I'm running version 5.19, Mike. Maybe not the most current, but a little ridiculous that it would be BLOCKED.
There seems to be a misunderstanding here. Recent versions of IDM should be blocklisted on pre-release versions of Firefox 4 because they are causing a very large amount of crashes. There are two problems here: 1) The blocklist page hasn't been updated, so it still points to an old block that in turn points to this bug. The bug for the new block is bug 578443. 2) Can any of the previous (or future) commenters mention which version of Firefox you're using? All 3.6 releases should work fine, only 4.0b1 and 3.7alpha versions should be blocked.
I just updated to Firefox 3.6.7 and IDM is now completely blocked!! The IDM CC add-ons v6.9.8 and the newest v6.9.9 are blocked by Firefox. How can you just completely ban Internet Download Manager? Fix Firefox 3.6.7 so that I can use the latest IDM 5.19 Build 3 with the latest Firefox IDM add-ons 6.9.8 or 6.9.9.
PLEASE READ THIS BEFORE POSTING A COMMENT Bug 578443 was meant to implement a limited block on IDM, but it was applied incorrectly, and now it seems that most users are being affected. We're trying to fix this problem as soon as possible, and we apologize for the inconvenience. We didn't mean to block IDM for everybody.
Sorry for my previous tone...I'm just a little frustrated. I'm using FF version 3.6.7, IDM add on version 6.9.8, and IDM version 5.19, for what it's worth.
Whiteboard: [see comment #107 before posting]
My tone was a bit off as well. I am using FF v3.6.7 and IDM Add-On version 6.9.1
I am using FF V3.6.7 and IDM Addon V6.7 (Which was working Juuust fine btw) But is blocked ! I thought only IDM CC 6.9 is only blocked !!
Attached file kernel32.dll mistakenly attached by Alex (obsolete) (deleted) —
Attachment #458912 - Flags: review+
Attachment #458912 - Flags: feedback+
Attachment #458912 - Flags: approval1.9.2.8?
I think this is stupid. Not once, or ever had I one single crash from IDM. Looking at platform, win Xp. I;m not even using this at all. How about your restore, as I have fully paid for IDM, and would like to fully use it. Now I cant even download my youtube or other videos and anything else. Even have problems now download from certain sites. Lame, guess I'll use another browsers, just dont screw with roboform either too.
Comment on attachment 458912 [details] kernel32.dll mistakenly attached by Alex Alex, please don't attach dll's to bugs. Thank you (In reply to comment #110) > I am using FF V3.6.7 and IDM Addon V6.7 (Which was working Juuust fine btw) > > But is blocked ! > I thought only IDM CC 6.9 is only blocked !! No, all version were accidentally blocked. See comment #107
Attachment #458912 - Attachment description: Trunk topcrash on startup [@ MultiByteToWideChar] [@ kernel32.dll + 0x9dea] involving Internet Download Manager → kernel32.dll mistakenly attached by Alex
Attachment #458912 - Attachment is obsolete: true
Attachment #458912 - Attachment is patch: false
Attachment #458912 - Flags: approval1.9.2.8?
Added note, I'm using IDM 5.16 Build 3, addon version 6.9.8. Not one crash ever.
Reposting to try to lessen additional posts (In reply to comment #107) > PLEASE READ THIS BEFORE POSTING A COMMENT > > Bug 578443 was meant to implement a limited block on IDM, but it was applied > incorrectly, and now it seems that most users are being affected. We're trying > to fix this problem as soon as possible, and we apologize for the > inconvenience. > > We didn't mean to block IDM for everybody.
Attached file IDM —
Hey! What a hell? I'm using Windows 7 with my favorite browser MOZILLA! Why I can't use IDMCC with it? Is it my mistake that someone work on XP platform and his kernel32 library don't work properly? I want to use my IDM! UNBLOCK this function. Or just give instructions how to unblock installation of idmmzcc.xpi
(In reply to comment #117) If you read 2 comments up from where you were typing you would know what the problem is. (In reply to comment #107) > PLEASE READ THIS BEFORE POSTING A COMMENT > > Bug 578443 was meant to implement a limited block on IDM, but it was applied > incorrectly, and now it seems that most users are being affected. We're trying > to fix this problem as soon as possible, and we apologize for the > inconvenience. > > We didn't mean to block IDM for everybody.
The change has been rolled back and Firefox will automatically re-enable IDM within 24 hours. If you'd like to make it re-enable immediately you can do the following: Open Tools -> Error Console In the code box paste the following line (all of it should be one line from Components to (null);. Components.classes["@mozilla.org/extensions/blocklist;1"].getService(Components.interfaces.nsIBlocklistService).QueryInterface(Components.interfaces.nsITimerCallback).notify(null); Press enter
What the hell you doing!!!! I can't download anything via IDM right now... Never met that idiot kernel crash or something like that before... Unblock it please for god sake... Ohh I forgot, IE do not block IDM... Let's use IE now my friend!!!
(In reply to comment #120) > What the hell you doing!!!! I can't download anything via IDM right now... > Never met that idiot kernel crash or something like that before... Unblock it > please for god sake... Ohh I forgot, IE do not block IDM... Let's use IE now my > friend!!! Please read the comment immediately above the one you typed.
SOLUTION OVER HERE!!! http://www.internetdownloadmanager.com/support/firefox_integration.html INSTALL AT THE BOTTOM OF THE PAGE AND ITS SOLVED ;D
im not able to acess the IDM 5.18 version with my Firefox 3.6.7 as first it was fine in working with Firefox but after a day or two Firefox was crashed& IDM stopped working with Firefox even i tried to install the whole setup again but all was useless as firefox says the add on IDM CC 6.9.9 has a high risk of causing stability& security problems& cant be installed. Please help
(In reply to comment #123) > im not able to acess the IDM 5.18 version with my Firefox 3.6.7 as first it was > fine in working with Firefox but after a day or two Firefox was crashed& IDM > stopped working with Firefox even i tried to install the whole setup again but > all was useless as firefox says the add on IDM CC 6.9.9 has a high risk of > causing stability& security problems& cant be installed. > > Please help Do as i say! is going to work!
the latest version of IDM CC at http://www.internetdownloadmanager.com/idmmzcc/4.02b/idmmzcc.xpi (6.9.9) fixed the issues and compatibility problems with firefox 4.
I'm really tired to write to Firefox forums that 1. IDM CC 6.9.9 has a workaround and Firefox 3.7 and 4.0 DO NOT crash anymore with this version of extension 2. The reason of crash is FIREFOX BUG inside nsISeletion::ToString() implementation! Please FIX your bug instead of blacklisting! Best regards, Charles Jones Software engineer Tonec Inc. 641 Lexington Avenue, 15th fl. New York, NY, 10022
(In reply to comment #126) > 2. The reason of crash is FIREFOX BUG inside nsISeletion::ToString() > implementation! Please FIX your bug instead of blacklisting! What is the bug exactly? Have you filed a bug on the issue you're seeing?
It's a bug in Firefox 3.7 and 4.01 and this Firefox bug is causing crashes. There are no bugs in IDM add-on. IDM CC 6.9.8 and below may (or may not) cause problems with Firefox 3.7 and 4.01 because of Firefox 3.7 and 4.01 bug IDM CC 6.9.9 should not cause any problems with any version of Firefox except 4.02 which needs a separate xpi for installation. IDM CC 6.9.9 has a workaround for Firefox 3.7 and 4.01 bug and it should not be blocked by Mozilla. It seems that they blocked IDM add-on all versions completely. And it's by mistake.
The content of attachment 458912 [details] has been deleted by Reed Loden [:reed] (sporadically busy until Aug. 6th) <reed@reedloden.com> who provided the following reason: Copy of kernel32.dll that has nothing to do with this bug. The token used to delete this attachment was generated at 2010-07-21 03:30:49 PDT.
Attached file AADT (obsolete) —
Comment on attachment 458980 [details] AADT Thanks for attaching the blocklist but there was already one attached which contains the same info for IDM as yours so, no need to attach any more of them. :)
Attachment #458980 - Attachment is obsolete: true
Robert how could fix up the bug please let me knw even if anyone else too knows that help me as i only use firefox for browsing & if this isnt fixed up soon ill be like a man with no hands left
there are no crash with my firefox and IDM! jancuk no I can't download with IDM in firefox maybe now I will using IE ;)
what's the matter with you? Why firefox 3.6.7 suddenly mark IDM add on as incompatible,while it worked without a single hickup since Firefox 3.5. You've got to change something that make IDM's add on useless.. Fix it, would ya.. and fast !!!
(In reply to comment #119) > The change has been rolled back and Firefox will automatically re-enable IDM > within 24 hours. If you'd like to make it re-enable immediately you can do the > following: > > Open Tools -> Error Console > In the code box paste the following line (all of it should be one line from > Components to (null);. > > Components.classes["@mozilla.org/extensions/blocklist;1"].getService(Components.interfaces.nsIBlocklistService).QueryInterface(Components.interfaces.nsITimerCallback).notify(null); > > Press enter tried this method already, but got another error message instead :( Error: uncaught exception: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.statusText]" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: file:///C:/Program%20Files/Mozilla%20Firefox%203.6%20Beta%203/components/nsBlocklistService.js :: anonymous :: line 469" data: no] what should I do??? Please come up with a remedy, a working one, that is...
**** u ! My firefox is working fine, my IDM-CC is working fine. And one day you just blacklist my add-on, claiming it's for stability and security ??? WTF !!@#@$% I'm switching to Chrome. God damn whoever made up this stupid blacklisting.
What have you guys done to this otherwise great browser. I am not able to open half the secure site that i use for my workplace. I work for Adobe and i can foresee a hell lot of compatibility issues now with our enterprise applications. I have no other choice to recommend this browser to be added to an un-supported browser list along with other like netscape etc. I am really disappointed with way things have been handled. i understand that the browser might have issues with certain plug-ins but each user has a standalone copy. It should be up to him to decide if to turn that feature off or keep it. Business might depend on it. I would appreciate if something can be done to revert these changes back or atleast a workaround is implemented.
For those of you that are unable to get the code to work in the error console you can delete the following from blocklist.xml which is located in your profile. Your profile can be found via the info in the following link http://support.mozilla.com/en-US/kb/profiles Open blocklist.xml in a text editor Remove the following from blocklist.cml <versionRange> <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}"> <versionRange minVersion=" " maxVersion="3.7"/> </targetApplication> </versionRange>
Hi Robert, Thank you for your extended help in this matter. That really helped. I was able to get my sites working for me. I will check for other compatibilities and get back to you. Appreciate your help. Dipankar
(In reply to comment #138) > For those of you that are unable to get the code to work in the error console > you can delete the following from blocklist.xml which is located in your > profile. Your profile can be found via the info in the following link > http://support.mozilla.com/en-US/kb/profiles > > Open blocklist.xml in a text editor > Remove the following from blocklist.cml > > <versionRange> > <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}"> > <versionRange minVersion=" " maxVersion="3.7"/> > </targetApplication> > </versionRange> thanks it really work but I remove all part <emItem id="mozilla_cc@internetdownloadmanager.com"> ...... </emItem>
Unfortunately, blocking all versions of IDM without notice has deprived me and my business of a service we have paid for (yes, we paid for IDM). The implied contract of support by Mozilla was broken when all versions of IDM were blocked without notice. Failure on Mozilla's part to rectify their error in a timely manner has exacerbated the situation and my company's loss. At a minimum, to prevent further issues, we have switched to Google's Chrome... and with a certain tete-a-tete, I have placed Firefox on our company's blacklist of forbidden software.
Flags: in-testsuite?
Flags: in-litmus?
Flags: in-testsuite?
Flags: in-litmus?
Attached file sf (obsolete) —
Attachment #529298 - Attachment is obsolete: true
Flags: in-testsuite+
Flags: in-litmus+
Attached patch tyhtjnr (obsolete) — — Splinter Review
IDM CC
Attachment #536934 - Attachment is obsolete: true
Flags: in-testsuite+
Flags: in-litmus+
Crash Signature: [@ MultiByteToWideChar] [@ kernel32.dll + 0x9dea]
Product: addons.mozilla.org → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: