User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9 I mistakenly disabled the "allow websites to install software" option in Options>Advanced>Software Update, thinking that this would eventually lead to adware-style installations. When using the Mozilla Update website, when you click the Install links, they look like they're being loaded and then do nothing (as described in the probably invalid <a href="show_bug.cgi?id=247551">bug 247551</a>). Clearly, not changing the pref would've been a smart move, but it would be useful if Firefox popped up an alert saying "Your preferences currently prohibit websites from installing software. Use Tools>Options>Advanced to enable software installation." Reproducible: Always Steps to Reproduce: 1. Uncheck preference "allow websites to install software" 2. Try to install extensions from http://update.mozilla.org Actual Results: Progress bar stutters, then nothing happens. Expected Results: Alert warning that software installation is currently disabled.
I would think that we might want to handle this via the statusbar, but some feedback is a good thing. Maybe something along the lines of the blocked popups would be good, and extensible to the whitelisting concept.
Severity: enhancement → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
15 years ago
Priority: -- → P3
The first step in tackling this bug would be to take care of bug 77518, i.e. rewording the preference in question to "Allow websites to install extensions/themes," or even better, "Allow installation of extensions/themes." At the moment it just sounds too dangerous.
Depends on: 77518
*** Bug 250484 has been marked as a duplicate of this bug. ***
I spent about 20 minutes trying to install the shell fix for Mozilla Firefox 0.9.1 with no hint as to why it refused to install. Implementing a simple dialog box that would inform the user that the installation was prohibited because of this option would be easy and should be done.
Same problem here with installing the shell patch. Furthermore, saving the .xpi to my hard drive and trying to install it from there failed too, so the wording of this option is misleading. Perhaps it should be re-worded to something more like, "Never install software" because that's really what is happening when this option is selected. That's just a band-aid though, I too would like to see a dialog letting me know I have disabled .xpi installations, or some other way of handling this.
*** Bug 250573 has been marked as a duplicate of this bug. ***
fixes: - this bug (shows a browser message when software installation pref is disabled) - xpinstall blocked/popup blocked observers are not removed at shutdown - xpinstall enabled pref is not disabled.
fixed branch only, uses browser message work dependent on 241705
Depends on: 241705
I had a very similar problem when installing Firefox PR1.0 over version 0.9 . I previously had the "allow websites to install software" option disabled. When I started PR1.0 for the first time, it prompted me to download updates for all my extensions. After I agreed to download the updates, the download progress dialog was shown, but it appeared to "stall" with no visible progress-bar; all the buttons at the bottom were greyed-out, and I could only close the dialog from the X in the top-right corner. Is this basically another instance of the same bug?
That has nothing to do with this bug.
I think a big part of the problem is people unchecking the box when they don't know exactly what it does. I like the suggestion in comment #5 ("never install software"). Another possibility is "Install software: Prompt, Disable" (IE-style). Comment #3 raises another good point -- we should say something clearer than "software" if all that is blocked are extensions, themes, and updates. This is an easy but important cosmetic fix because the current label clearly causes a lot of confusion and it makes the default settings look less secure.
Um, with the automatic blocking of all extension/theme installs from sites not in the whitelist, why would we have a user-preference that sets a behaviour to turn off installs altogether? That's where the confusion seems to exist - in the combination of both a whitelist *and* a "allow/disallow *all* installs" option. Could we not just have a radio button in the whitelist dialog that says "Never allow any software installs"? Or would that be a new bug?
Fixed by branch landing.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Whiteboard: not fixed on trunk yet, depends on bug 241705
The info bar is still not displayed in Windows trunk builds. That's because bug 241705 is not fixed on trunk yet.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: not fixed on trunk yet, depends on bug 241705 (Windows at least)
I just tested it on a Windows trunk build, and the info bar appears just fine. You've tested it and gotten different results?
In fact, as you noted at bug 241705 comment 28, most of that bug's functionality also got moved to trunk during the landing.
The info bar doesn't appear here when clicking a link at u.m.o: 1. disable "allow web sites to install software" 2. click the install link at e.g. https://addons.update.mozilla.org/extensions/moreinfo.php?id=10&application=firefox Result: Nothing happens. The info bar does appear when clicking the install link on http://hacksrus.com/~ginda/chatzilla/ The first uses InstallTrigger, the second is just a plain <a href="chatzilla.xpi">. And the bits I noted in bug 241705 comment 28 are still missing on trunk.
Whiteboard: not fixed on trunk yet, depends on bug 241705 (Windows at least) → InstallTrigger links not fixed on trunk yet, depends on bug 241705
(In reply to comment #17) > The info bar doesn't appear here when clicking a link at u.m.o: > 1. disable "allow web sites to install software" > 2. click the install link at e.g. > https://addons.update.mozilla.org/extensions/moreinfo.php?id=10&application=firefox > Result: Nothing happens. I see an info bar using both links. I guess UMO uses some kind of fallback if InstallTrigger fails? But you're right, the nsInstallTrigger.cpp part of the other patch wasn't checked in (windbgdlg.cpp isn't relevant), and I should have noticed that.
No longer depends on: 77518
Version: unspecified → Trunk
Shouldn't this bug be closed because Bug 274271 takes care of installtrigger bug ?
Due to the security hole, I unchecked the "Allow web sites to install software" option. I got an alert about the Tabbed Browsing extension being updated, and clicked on the update. It tried to download the update and just hung with no message. I had to manually close the download window, re-enable install software, and update it. It should, when updates are available, give a warning that it cannot update if installation is disabled rather than just hang.
Any remaining work is going to be done in bug 274271. *** This bug has been marked as a duplicate of 274271 ***
Status: REOPENED → RESOLVED
Last Resolved: 14 years ago → 14 years ago
No longer depends on: 241705
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.