Steps to reproduce: 1) Unknown but possibly has to do with Windows performing an automatic restore to a system restore point as part of recovering from a system crash. 2) Start Firefox. Actual results: A dialog saying "couldn't load XPCOM" is shown. Dismissing the dialog makes the app exit. The user is more likely to turn to Chrome than to figure out that reinstalling Firefox would fix the problem. Expected results: Expected Mozilla Maintenance Service to have the capability of silently and automatically reinstalling Firefox when the Firefox installation is detected to be broken. Whenever Firefox itselt is about to show a dialog like the one mentioned above, it should instead signal to the Maintenance Service to request reinstallation. The Maintenance Service should also check the integrity of the Firefox installation daily (by computing hashes of all files) and trigger the reinstall if the integrity check fails.
I don't think we should try to do this. The Mozilla Maintenance Service has no ability to access the network so it can't download a new installer. Which means you'd have to keep a copy of all the files, or a full MAR somewhere which would waste disk space. Some people don't have a lot of extra disk space. What I think we should do here instead is give the Message Box "Couldn't load XPCOM, please re-install Firefox", and when they hit OK we open IE to the mozilla firefox download page.
Summary: Mozilla Maintenance Service should do an automatic reinstall when Firefox is broken → Improve flow when Firefox is broken
Component: Application Update → General
Product: Toolkit → Firefox
(In reply to Brian R. Bondy [:bbondy] from comment #1) > The Mozilla Maintenance Service has no ability to access the network so it > can't download a new installer. Can't we include a small less privileged downloader in the Maintenance Service package? Manually having to reinstall is a big step when Chrome already sits on your computer as foistware/OEMware.
Are there numbers for how many users are affected by this? We've made efforts to prevent system restore from breaking Firefox and I suspect that this is extremely rare to non-existent. If it is cropping up as a problem again we can fix the case where Firefox breaks.
Also, the maintenance service doesn't have network access to limit the attack surface and I don't think the value would outweigh opening this attack vector.
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #3) > Are there numbers for how many users are affected by this? Not that I'm aware of. I saw this happen to someone who I visit a couple of times a year and install whatever updates that hadn't been autoinstalled on their Vista laptop. The saying is that each failure you see yourself represents a large amount of other failures, but of course I don't know what the exact factor is here. The failure is pretty recent. Probably started failing in August and I fixed the situation in October. I didn't witness the start of the problem. My guess of what the root cause was is based on Googling around for support.mozilla.org and mozillazine knowledge base. Anyway, the dialog was incomprehensible. The person didn't know what XPCOM was and wondered about "XP", since the laptop was running Vista and not XP. Meanwhile, Chrome had shown up on the computer (probably via Google front page nagging and curiousity) and the person had been using Chrome for a couple of months until I reinstalled Firefox. This is how we lose users (unless they personally know Firefox devs who come over and fix stuff). I really think the Mozilla Maintenance Service should be accompanied with a small less privileged downloader that'd make automatic reinstallation possible.
This flow could definitely be improved, but I don't see a reason why you'd want to involve the Mozilla Maintenance Service. The name of the maintenance service binary makes it look like it's a good candidate, but it's just a name. At the time this error is given, the Firefox process is running, but it can't load a crucial dll. It can therefore instead fallback to prompting the user and asking if they want to re-install. If they select yes, then the code can re-download and initiate the installer. Using the service complicates things a lot, and introduces risk. And the only benefit is that things could potentially be fixed silently. But of course adding this complexity would be likely to fail in some cases, and I would want reports if a general bug like this happened. I don't think this happens enough to warrant the extra complexity added to the maintenance service code just to get a silent fix to this problem. And I don't think a silent fix to this problem is a good idea. Also, having a high integrity process start another one is risky business from a security standpoint so is not worth the security risk either. So I don't think the mozilla maintenance service is a good fit for this particular bug report. As mentioned at the top though, the flow can be improved, just not by the method that you indicated.
You need to log in before you can comment on or make changes to this bug.