Closed Bug 310737 (xpinstall.enabled) Opened 19 years ago Closed 18 years ago

1.0.x users have no way to re-enable software installation (message bar that appears when xpinstall.enabled is false points to removed UI)

Categories

(Firefox :: Settings UI, defect, P1)

1.5.0.x Branch
defect

Tracking

()

RESOLVED FIXED
Firefox 2 alpha2

People

(Reporter: asaf, Assigned: steffen.wilberg)

References

Details

(Keywords: fixed1.8.1, relnote, useless-UI, Whiteboard: [l10n impact] [see comment #42 for instructions on how to fix])

Attachments

(2 files, 6 obsolete files)

Under bug 288054, we've removed the UI for xpinstall.enabled. That's fine for
anyone who hasn't disabled it in 1.0.x/deepark. However,  if it was turned off,
there's no way to re-enable it in 1.5 (except about:config).

Also, if xpinstall is disabled (by old UI, or by about:config), the message bar
which appears when one tries to do install an XPI points to removed UI.

One way to resolve it is to change the xpinstall message bar to have a "Allow"
button instead of the "Edit Options" button.
Flags: blocking1.8b5?
Whiteboard: [l10n impact]
As per bug 288054 comment 64, the original problem (update service not working
when xpinstall.enabled was false) apparently no longer exists, and it looks like
bug 307928 (disable update controls in EM when xpinstall.enabled is false) is
getting close to being done as well.

With all this in mind, it might just be better to back out the patch from bug
288054 and return control over xpinstall.enabled to the user.
If the patch for bug 288054 is backed out and the incorrect text is changed from
allow web sites to install software it would be great if the text made it
clearer that this setting affects updates as well as installs and should refer
to something along the lines of addons as discussed on irc to avoid confusion
with application update... and of course the fact that it disables all installs
vs. web sites as it stated before.
Blocks: 310545
Some options for the new, more accurate pref:

[ ] Add ons can be installed and updated                      [ Allowed Sites ]

-- or --

[ ] Extensions, plugins and themes can be installed & updated [ Allowed Sites ]

There is another alternative, and although I'm loathe to suggest adding more
preferences, it might just be easier to not confuse the whole "it's on/off"
thing with the whitelist thing:

[ ] Extensions, plugins and themes can be installed & updated
    [ ] Only certain web sites can install extensions         [ Allowed Sites ]

Please comment, as I feel I'm losing some perspective on this issue.
The last one is the most accurate since allowed sites only applies to the
whitelist - otherwise it appears that allowed sites applies to updates which it
doesn't. The other two - though more accurate than what we had before - would
just change what people are confused about. It might be better to change the
text on the second item to something along the lines of (needs better verbiage):
Only certain sites can initiate extension installs

The reason is that many people believe the whitelist prevents user initiated
installs for sites not listed. Either way it works for me and I believe the
majority of the users would understand it either way.
Time is running out (and will have ran out in about 10 hours) so if this is
gonna make the 1.5 train, it'll need to happen real soon.
Attached patch patch (obsolete) — Splinter Review
This does the right thing for disabling / enabling the widgets... had to do
more than I had thought it would take.
Attachment #198377 - Flags: review?(mconnor)
Attached image screenshot (obsolete) —
using Mike's 3rd example.
Perhaps it would be just as good to not have the checkbox to disable
whitelisting per the 3rd example and just have a label? Then the label could be
associated with the button for what it accomplishes without associating the
xpinstall.enabled label with whitelisting.
But if xpinstall.enabled=false, then the whitelist never really gets checked,
right? What I worry about there is that users might interpret the first
preference (corresponding to xpinstall.enabled) to be a global statement with
exceptions provided by the second (which corresponds to
xpinstall.enabled.whitelist).
True though the button would be disabled for the exceptions. Also, with the
checkbox it is easier to keep the look in the ui consistent. I copied your text
verbatim so if you want something changed please say so. I used the first
accesskey available on the panel as can be seen in the screenshot.
Thanks, Rob. A few suggested tweaks:

<!ENTITY  enableExtWhitelist.label    "only allow certain web sites to install
extensions">
<!ENTITY  allowedSitesSoftware.label  "Allowed Sites">

You'll have to shuffle the accesskeys around as well:

<!ENTITY  enableExtWhitelist.accesskey      "x">
<!ENTITY  allowedSitesSoftware.accesskey    "o">

(note that I'm also suggesting that the label for the button switch back to
allowedSitesSoftware.label|accesskey to alert l10n, although if this gets taken,
we'll need to alert the l10n folk, too)

This should leave us with:

.------------------------------------------------------------------------------.
|[ ] Block Popup Windows                                       [Allowed Sites] |
|[ ] Extensions, plugins and themes can be installed & updated                 |
|     [ ] only allow certain web sites to install extensions   [Allowed Sites] |
|[ ] Load Images                                               [ Exceptions  ] |
|     [ ] for originating website only                                         |
|[ ] Enable Javascript                                                         |
|[ ] Enable Java                                               [ Advanced... ] |
|                                                                              |
'------------------------------------------------------------------------------'
Attached patch updated per comments (obsolete) — Splinter Review
Also changed the onsyncfrompreference for enableExtensionWhitelist since the
button's disabled state could be overruled by xpinstall.whitelist.required when
xpinstall.enabled was false.
Attachment #198377 - Attachment is obsolete: true
Attachment #198380 - Attachment is obsolete: true
Attachment #198395 - Flags: review?(mconnor)
Attached image sreenshot (obsolete) —
As per IRC conversation with mconnor, this shouldn't be blocking 1.5b2, but
should definitely be resolved before 1.5final.
Flags: blocking1.8b5? → blocking1.8b5-
*** Bug 312204 has been marked as a duplicate of this bug. ***
*** Bug 312204 has been marked as a duplicate of this bug. ***
nominating (see comment 14)
Flags: blocking1.8rc1?
At the very least, we should reslove the message bar issue.
Attached patch patch (obsolete) — Splinter Review
1) Reset xpinstall.enabled to true on first startup 2) Replace the message bar
with an alert (for those who turn off xpinstall.enabled via about:config).
Assignee: nobody → bugs.mano
Attachment #198395 - Attachment is obsolete: true
Attachment #198396 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #199702 - Flags: review?(mconnor)
Priority: -- → P1
Target Milestone: --- → Firefox1.5rc1
How about showing an Enable button on the info bar?
"Software installation is currently disabled. Click Enable to enable it and try
again."
(In reply to comment #20)
> How about showing an Enable button on the info bar?
> "Software installation is currently disabled. Click Enable to enable it and try
> again."

I believe that the argument goes that sysadmins might want to be able to prevent
their users from being able to install extensions (as it's a security risk to
their terminals).

Mano/mconnor: if we flip this pref, we're gonna have to make sure that it gets
into whatever release note documentation accompanies the platform for any
sysadmins who were trying to control extension installs this way. I'm still not
entirely sold that we want to flip the pref for migrated profiles, really ...
Not going to block the release on this but we'd consider a fully reviewed and
verified on the trunk patch to repair the information bar, if our Localization
team doesn't threaten to murder us all.
Flags: blocking1.8rc1? → blocking1.8rc1-
attachment 198395 [details] [diff] [review] is also still an option - what ever method is chosen there
would be a l10n impact. The only thing it is missing is handling the case where
the pref is locked like the majority if not all of the prefpanels and it keeps
the status quo of using the browsermessage which is a good thing for the sake of
consistency as well as not using an alert.
With EuroOSCON-BarCamp-no-sleep, if we can arrange for a travel budget, I can sure
find some l10n team to make some time to head out and kill you ;-).

*If* we want to take a patch, please write up a thorough doc to be posted to l10n 
to explain the actual change, attachment 198395 [details] [diff] [review] is not something that I understand
ad-hoc or by glancing over the bug comments. Looking at the screenshot 198396,
selecting "only allow certain web sites to install extensions" doesn't look like
a thing that I would want on. (With my brains off only, of course, but that's 
what we want to safeguard, right?)
*** Bug 313600 has been marked as a duplicate of this bug. ***
Comment on attachment 199702 [details] [diff] [review]
patch

alerts suck.  There was a minor bit of discussion between Mano and I where it was agreed that the modal dialog wasn't a good thing, and what we wanted was to make the button text simply "close" since we apparently can't not have it.
Attachment #199702 - Flags: review?(mconnor) → review-
Keywords: relnote
Should get a low-bar fix in for RC2: change the dialog to say "Software install is disabled [x]" and remove the [Options..] button. Mano, do you have time to whip that up for us?
Flags: blocking1.8rc2?
Flags: blocking1.8rc2?
Mano: sorry, my bad, I misunderstood criteria for RC2. nm on that patch request!
Mano mentioned on irc regarding an earlier patch that the pref panel should respect the xpinstall.enabled which I agree with so I am mentioning it here so it doesn't get overlooked when this is fixed on the trunk.

If xpinstall.enabled is false the pref ui for "Warn me when web sites try to install extensions and themes" should probably be disabled - preferably with why it is disabled - since it is not possible to warn when this pref is false or for that matter have allowed sites.
Flags: blocking-aviary2+
*** Bug 315072 has been marked as a duplicate of this bug. ***
Summary: 1.0.x users has no UI way to re-enable software installation (xpinstall message bar points to removed UI) → 1.0.x users have no way to re-enable software installation (xpinstall message bar points to removed UI)
Please don't ship 1.5 without a patch or it will become very crowded on the support forums! :)
See Bug 317099.
*** Bug 317099 has been marked as a duplicate of this bug. ***
Using RC3 and still I can not add an extension easily.  
I follow the "Get more extensions" link from the extensions window.
I find an extension I like, I click "Install Now" and the popup blocker appears.
It has a nice button for changing extension permission, but no matter what I select it refuses to download the extension to load.  Please just add a button that says "Allow Install".  How freaking hard is this.  Your present system sucks.  It is good that a website is blocked from secretly adding an extension, but the system is so poorly designed that even when a user WANTS an extension he/she is prevented from doing so.  MAKE IT SIMPLE!!!
*** Bug 317310 has been marked as a duplicate of this bug. ***
*** Bug 317957 has been marked as a duplicate of this bug. ***
*** Bug 318197 has been marked as a duplicate of this bug. ***
*** Bug 318318 has been marked as a duplicate of this bug. ***
*** Bug 318321 has been marked as a duplicate of this bug. ***
*** Bug 318354 has been marked as a duplicate of this bug. ***
*** Bug 318359 has been marked as a duplicate of this bug. ***
Flags: blocking1.8rc1-
Flags: blocking1.8b5-
Flags: blocking1.8.0.1?
*** Bug 318426 has been marked as a duplicate of this bug. ***
Quoting "http://www.mozilla.com/firefox/releases/1.5.html":

"If you disabled xpinstall in Firefox 1.0.x by unselecting the Allow Web sites to Install Software preference (changed in Firefox 1.5), use about:config to set the xpinstall.enabled preference to true to re-enable installs."

This basically means going to "about:config" in your address bar, searching for "xpinstall.enabled", and changing the value to true by right-clicking and selecting "Reset" to set it back to the default.
Whiteboard: [l10n impact] → [l10n impact] [see comment #42 for instructions on how to fix]
Alias: xpinstall.enabled
*** Bug 318517 has been marked as a duplicate of this bug. ***
*** Bug 318579 has been marked as a duplicate of this bug. ***
*** Bug 318649 has been marked as a duplicate of this bug. ***
Changed xpinstall.enabled to true as recomended in comment #42.

The next problem was none of the very few extensions that are rated for 1.5 would install because of some problem with chrome not being properly registered.

Have uninstalled 1.5 and re-installed 1.07. Will wait till the bugs are worked out of 1.5.

As this was a known problem, 1.5 should not have been released, better to hold off a few days rather than chase users away.

If less devoted/new FireFox users run into this problem, and they have, they will no doubt go back to IE and never return.

In any case thanks to all that work on FireFox, I will continue to spread the word. Just not on 1.5 for awhile.
*** Bug 318871 has been marked as a duplicate of this bug. ***
So if xpinstall is disabled and the pref is locked, which means that an adminstrator doesn't want the user to install software, we should tell the user "Sorry, you are not allowed to install software in Firefox."

If however the pref is not locked, the user should be able to re-enable xpinstall by clicking an Enable button on the info bar. That would help users who have disabled xpinstall in 1.0.x and wonder why they can't re-enable it in 1.5.

The patch also enables the close button on the info bar.
Attachment #204923 - Flags: review?(mconnor)
*** Bug 318906 has been marked as a duplicate of this bug. ***
The strings aren't right, but the patch is technically correct.

Problems I don't have cycles to think about today:

Re-enabling doesn't have a clear result, but with whitelisting and a clear dialog, this isn't so bad.  (beltzner?)

Sorry shouldn't be used in strings.  Perhaps "Software installation has been disabled by your system administrator." is better.
*** Bug 319126 has been marked as a duplicate of this bug. ***
On windows here's what I see:
I ran into this, and guessed correctly the cause.  So I uninstalled firefox 1.5.  But, it's sticky!!  The new firefox 1.5 picked up my old themes and prefs. 

So I uninstalled again, and deleted c:\program files\firefox.  Now the themes are gone.  But the prefs are still sticky!!

To prevent future bugs like this, how can firefox be really really really removed?
You don't need to "really really remove Firefox" to fix this. The explanation is in this bug, and also in the FAQ in the support forum, which would have been the right place for your question. The post in the support forum also explains how to remove your profile, if you really really want to). http://forums.mozillazine.org/viewtopic.php?t=341279
*** Bug 319692 has been marked as a duplicate of this bug. ***
An option to ignore the old profile, at install time, could go a long way to addressing this entire class of bugs.  Is it worth submitting a patch?
*** Bug 317763 has been marked as a duplicate of this bug. ***
*** Bug 319759 has been marked as a duplicate of this bug. ***
*** Bug 319952 has been marked as a duplicate of this bug. ***
*** Bug 319994 has been marked as a duplicate of this bug. ***
*** Bug 320061 has been marked as a duplicate of this bug. ***
Flags: blocking1.8.1?
Jonathan, I'm pretty sure the blocking1.8.1 flag is redundant is light of the fact that this bug has already been accepted as a blocker for 2.0, since 2.0 will be released off of the yet-to-be-created 1.8.1 branch.
Sorry, you are right.

I'll remove that flag.
Flags: blocking1.8.1?
I am an average day to day user trying to get away from IE and Outlook. I see solutions to the problems I have, but I don't understand them. Can anyone help me in plain english?
My problems are:
I cannot themes in Firefox and
Sunbird will not open unless I re-download the program, then it opens once and has kept all the appointments etc.
(In reply to comment #63)
> I am an average day to day user trying to get away from IE and Outlook. I see
> solutions to the problems I have, but I don't understand them. Can anyone help
> me in plain english?

Bugzilla is not the place for average users to get support, please visit the support forums at http://forum.mozillazine.org or log onto IRC http://irc.mozilla.org for user support.

Sorry for the bugspam everyone.
*** Bug 321218 has been marked as a duplicate of this bug. ***
Fix is to open 1.0.7 browser (if older version is still installed) and turing option back on will let 1.5 Firefox to install extensions.
(In reply to comment #66)
> Fix is to open 1.0.7 browser (if older version is still installed) and turing
> option back on will let 1.5 Firefox to install extensions.

No need to use an older version, you can just follow the steps in comment 42.
Summary: 1.0.x users have no way to re-enable software installation (xpinstall message bar points to removed UI) → 1.0.x users have no way to re-enable software installation (message bar that appears when xpinstall.enabled is false points to removed UI)
*** Bug 321736 has been marked as a duplicate of this bug. ***
(In reply to comment #50)
> Problems I don't have cycles to think about today:
> 
> Re-enabling doesn't have a clear result, but with whitelisting and a clear
> dialog, this isn't so bad.  (beltzner?)
I don't think clicking the button on the info bar should trigger the xpinstall dialog right away. This doesn't happen after adding a site to the whitelist either: you have to click again on the extension install link. We should be consistent here.

> Sorry shouldn't be used in strings.  Perhaps "Software installation has been
> disabled by your system administrator." is better.
Fixed.
Assignee: bugs.mano → steffen.wilberg
Attachment #199702 - Attachment is obsolete: true
Attachment #204923 - Attachment is obsolete: true
Attachment #207072 - Flags: review?(mconnor)
Attachment #204923 - Flags: review?(mconnor)
We're not currently considering any l10n changes for the 1.5.0.1 release.
Flags: blocking1.8.0.1? → blocking1.8.0.1-
*** Bug 323289 has been marked as a duplicate of this bug. ***
Target Milestone: Firefox1.5rc1 → Firefox 2
iirc we have previously recommended disabling xpinstall for the iconURL bug. I mention this because if we don't add the ui back I don't think we could reasonably make this recommendation if we want to recommend disabling xpinstall as a work around to such a bug in the future (e.g. would require telling users to do this in about:config). On the other hand we have already bit the bullet by removing it.

If the ui to enable / disable it is not shown in the pref panel "Warn me when web sites try to install software" checkbox and associated "Exceptions" button should probably be disable when xpinstall.enabled is false since they only apply when xpinstall.enabled is true.
*** Bug 324845 has been marked as a duplicate of this bug. ***
Having read all the comments on this bug I find myself still saying the exact same thing; it was SO much easier in 1.0.7 to install themes and extensions. This really shouldn't require an about:config setting change -- it should merely be something in Tools/Options. A few clicks and you're all done.

I strongly urge you to consider making this easy again. After all, extensions and themes are some of Firefox's biggest selling points. Why diminish there significance by mkaing it so difficult to add them?
Flags: blocking1.8.0.2?
Can't accept l10n changes in 1.8.0.x for things like this.
Flags: blocking1.8.0.2? → blocking1.8.0.2-
Target Milestone: Firefox 2 → Firefox 2 alpha2
*** Bug 330341 has been marked as a duplicate of this bug. ***
*** Bug 332107 has been marked as a duplicate of this bug. ***
Comment on attachment 207072 [details] [diff] [review]
show an Enable button, v1.1

r=me, but we need to change the property names so l10n people find out about the changes.

beltzner, care to sign off on this?  Basically, it makes the Edit Options button label Enable, which just enables software install.  If the pref is locked by the network admin, the message will say that, and not show the button.
Attachment #207072 - Flags: ui-review?(beltzner)
Attachment #207072 - Flags: review?(mconnor)
Attachment #207072 - Flags: review+
Comment on attachment 207072 [details] [diff] [review]
show an Enable button, v1.1

signed off with a smile :)
Attachment #207072 - Flags: ui-review?(beltzner) → ui-review+
Attachment #207072 - Flags: approval-branch-1.8.1+
I changed the property names.
Trunk:
Checking in mozilla/browser/base/content/browser.js;
/cvsroot/mozilla/browser/base/content/browser.js,v  <--  browser.js
new revision: 1.605; previous revision: 1.604
done
Checking in mozilla/browser/locales/en-US/chrome/browser/browser.properties;
/cvsroot/mozilla/browser/locales/en-US/chrome/browser/browser.properties,v  <--  browser.properties
new revision: 1.24; previous revision: 1.23
done

1.8 branch:
Checking in mozilla/browser/base/content/browser.js;
/cvsroot/mozilla/browser/base/content/browser.js,v  <--  browser.js
new revision: 1.479.2.106; previous revision: 1.479.2.105
done
Checking in mozilla/browser/locales/en-US/chrome/browser/browser.properties;
/cvsroot/mozilla/browser/locales/en-US/chrome/browser/browser.properties,v  <--  browser.properties
new revision: 1.20.2.4; previous revision: 1.20.2.3
done
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Keywords: late-l10nfixed1.8.1
Resolution: --- → FIXED
*** Bug 332907 has been marked as a duplicate of this bug. ***
*** Bug 336476 has been marked as a duplicate of this bug. ***
*** Bug 336611 has been marked as a duplicate of this bug. ***
*** Bug 337116 has been marked as a duplicate of this bug. ***
*** Bug 338086 has been marked as a duplicate of this bug. ***
*** Bug 337729 has been marked as a duplicate of this bug. ***
*** Bug 339422 has been marked as a duplicate of this bug. ***
*** Bug 340910 has been marked as a duplicate of this bug. ***
*** Bug 344806 has been marked as a duplicate of this bug. ***
*** Bug 344807 has been marked as a duplicate of this bug. ***
*** Bug 345331 has been marked as a duplicate of this bug. ***
*** Bug 345623 has been marked as a duplicate of this bug. ***
*** Bug 347119 has been marked as a duplicate of this bug. ***
This is not acceptable on the 1.8.0 branch because of the string changes, right?
(In reply to comment #95)

Yes.
*** Bug 349083 has been marked as a duplicate of this bug. ***
*** Bug 352957 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: