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)
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)
5.06 KB,
patch
|
mconnor
:
review+
beltzner
:
ui-review+
mconnor
:
approval-branch-1.8.1+
|
Details | Diff | Splinter Review |
5.02 KB,
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Updated•19 years ago
|
Flags: blocking1.8b5?
Whiteboard: [l10n impact]
Comment 1•19 years ago
|
||
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.
Comment 2•19 years ago
|
||
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.
Comment 3•19 years ago
|
||
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.
Comment 4•19 years ago
|
||
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.
Comment 5•19 years ago
|
||
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.
Comment 6•19 years ago
|
||
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)
Comment 7•19 years ago
|
||
using Mike's 3rd example.
Comment 8•19 years ago
|
||
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.
Comment 9•19 years ago
|
||
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).
Comment 10•19 years ago
|
||
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.
Comment 11•19 years ago
|
||
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... ] | | | '------------------------------------------------------------------------------'
Comment 12•19 years ago
|
||
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)
Updated•19 years ago
|
Attachment #198377 -
Flags: review?(mconnor)
Comment 13•19 years ago
|
||
Updated•19 years ago
|
Attachment #198395 -
Flags: review?(mconnor)
Comment 14•19 years ago
|
||
As per IRC conversation with mconnor, this shouldn't be blocking 1.5b2, but should definitely be resolved before 1.5final.
Updated•19 years ago
|
Flags: blocking1.8b5? → blocking1.8b5-
Comment 15•19 years ago
|
||
*** Bug 312204 has been marked as a duplicate of this bug. ***
Comment 16•19 years ago
|
||
*** Bug 312204 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 18•19 years ago
|
||
At the very least, we should reslove the message bar issue.
Reporter | ||
Comment 19•19 years ago
|
||
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)
Reporter | ||
Updated•19 years ago
|
Priority: -- → P1
Target Milestone: --- → Firefox1.5rc1
Assignee | ||
Comment 20•19 years ago
|
||
How about showing an Enable button on the info bar? "Software installation is currently disabled. Click Enable to enable it and try again."
Comment 21•19 years ago
|
||
(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 ...
Comment 22•19 years ago
|
||
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-
Comment 23•19 years ago
|
||
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.
Comment 24•19 years ago
|
||
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?)
Comment 25•19 years ago
|
||
*** Bug 313600 has been marked as a duplicate of this bug. ***
Comment 26•19 years ago
|
||
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-
Comment 27•19 years ago
|
||
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?
Updated•19 years ago
|
Flags: blocking1.8rc2?
Comment 28•19 years ago
|
||
Mano: sorry, my bad, I misunderstood criteria for RC2. nm on that patch request!
Comment 29•19 years ago
|
||
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.
Reporter | ||
Updated•19 years ago
|
Flags: blocking-aviary2+
Comment 30•19 years ago
|
||
*** Bug 315072 has been marked as a duplicate of this bug. ***
Updated•19 years ago
|
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)
Comment 31•19 years ago
|
||
Please don't ship 1.5 without a patch or it will become very crowded on the support forums! :) See Bug 317099.
Comment 32•19 years ago
|
||
*** Bug 317099 has been marked as a duplicate of this bug. ***
Comment 33•19 years ago
|
||
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!!!
Comment 34•19 years ago
|
||
*** Bug 317310 has been marked as a duplicate of this bug. ***
Comment 35•19 years ago
|
||
*** Bug 317957 has been marked as a duplicate of this bug. ***
Comment 36•19 years ago
|
||
*** Bug 318197 has been marked as a duplicate of this bug. ***
Comment 37•19 years ago
|
||
*** Bug 318318 has been marked as a duplicate of this bug. ***
Comment 38•19 years ago
|
||
*** Bug 318321 has been marked as a duplicate of this bug. ***
Comment 39•19 years ago
|
||
*** Bug 318354 has been marked as a duplicate of this bug. ***
Comment 40•19 years ago
|
||
*** Bug 318359 has been marked as a duplicate of this bug. ***
Reporter | ||
Updated•19 years ago
|
Flags: blocking1.8rc1-
Flags: blocking1.8b5-
Flags: blocking1.8.0.1?
Comment 41•19 years ago
|
||
*** Bug 318426 has been marked as a duplicate of this bug. ***
Comment 42•19 years ago
|
||
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]
Updated•19 years ago
|
Alias: xpinstall.enabled
Comment 43•19 years ago
|
||
*** Bug 318517 has been marked as a duplicate of this bug. ***
Comment 44•19 years ago
|
||
*** Bug 318579 has been marked as a duplicate of this bug. ***
Comment 45•19 years ago
|
||
*** Bug 318649 has been marked as a duplicate of this bug. ***
Comment 46•19 years ago
|
||
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.
Comment 47•19 years ago
|
||
*** Bug 318871 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 48•19 years ago
|
||
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)
Comment 49•19 years ago
|
||
*** Bug 318906 has been marked as a duplicate of this bug. ***
Comment 50•19 years ago
|
||
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.
Comment 51•19 years ago
|
||
*** Bug 319126 has been marked as a duplicate of this bug. ***
Comment 52•19 years ago
|
||
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?
Comment 53•19 years ago
|
||
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
Comment 54•19 years ago
|
||
*** Bug 319692 has been marked as a duplicate of this bug. ***
Comment 55•19 years ago
|
||
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?
Comment 56•19 years ago
|
||
*** Bug 317763 has been marked as a duplicate of this bug. ***
Comment 57•19 years ago
|
||
*** Bug 319759 has been marked as a duplicate of this bug. ***
Comment 58•19 years ago
|
||
*** Bug 319952 has been marked as a duplicate of this bug. ***
Comment 59•19 years ago
|
||
*** Bug 319994 has been marked as a duplicate of this bug. ***
Comment 60•19 years ago
|
||
*** Bug 320061 has been marked as a duplicate of this bug. ***
Updated•19 years ago
|
Flags: blocking1.8.1?
Comment 61•19 years ago
|
||
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.
Comment 63•19 years ago
|
||
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.
Comment 64•19 years ago
|
||
(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.
Comment 65•19 years ago
|
||
*** Bug 321218 has been marked as a duplicate of this bug. ***
Comment 66•19 years ago
|
||
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.
Comment 67•19 years ago
|
||
(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.
Updated•19 years ago
|
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)
Comment 68•19 years ago
|
||
*** Bug 321736 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 69•19 years ago
|
||
(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)
Comment 70•19 years ago
|
||
We're not currently considering any l10n changes for the 1.5.0.1 release.
Flags: blocking1.8.0.1? → blocking1.8.0.1-
Comment 71•19 years ago
|
||
*** Bug 323289 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•18 years ago
|
Target Milestone: Firefox1.5rc1 → Firefox 2
Comment 72•18 years ago
|
||
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.
Comment 73•18 years ago
|
||
*** Bug 324845 has been marked as a duplicate of this bug. ***
Comment 74•18 years ago
|
||
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?
Updated•18 years ago
|
Flags: blocking1.8.0.2?
Comment 75•18 years ago
|
||
Can't accept l10n changes in 1.8.0.x for things like this.
Flags: blocking1.8.0.2? → blocking1.8.0.2-
Updated•18 years ago
|
Target Milestone: Firefox 2 → Firefox 2 alpha2
Comment 76•18 years ago
|
||
*** Bug 330341 has been marked as a duplicate of this bug. ***
Comment 77•18 years ago
|
||
*** Bug 332107 has been marked as a duplicate of this bug. ***
Comment 78•18 years ago
|
||
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 79•18 years ago
|
||
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+
Updated•18 years ago
|
Attachment #207072 -
Flags: approval-branch-1.8.1+
Assignee | ||
Comment 80•18 years ago
|
||
I changed the property names.
Assignee | ||
Comment 81•18 years ago
|
||
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-l10n → fixed1.8.1
Resolution: --- → FIXED
Comment 82•18 years ago
|
||
*** Bug 332907 has been marked as a duplicate of this bug. ***
Comment 83•18 years ago
|
||
*** Bug 336476 has been marked as a duplicate of this bug. ***
Comment 84•18 years ago
|
||
*** Bug 336611 has been marked as a duplicate of this bug. ***
Comment 85•18 years ago
|
||
*** Bug 337116 has been marked as a duplicate of this bug. ***
Comment 86•18 years ago
|
||
*** Bug 338086 has been marked as a duplicate of this bug. ***
Comment 87•18 years ago
|
||
*** Bug 337729 has been marked as a duplicate of this bug. ***
Comment 88•18 years ago
|
||
*** Bug 339422 has been marked as a duplicate of this bug. ***
Comment 89•18 years ago
|
||
*** Bug 340910 has been marked as a duplicate of this bug. ***
Comment 90•18 years ago
|
||
*** Bug 344806 has been marked as a duplicate of this bug. ***
Comment 91•18 years ago
|
||
*** Bug 344807 has been marked as a duplicate of this bug. ***
Comment 92•18 years ago
|
||
*** Bug 345331 has been marked as a duplicate of this bug. ***
Comment 93•18 years ago
|
||
*** Bug 345623 has been marked as a duplicate of this bug. ***
Comment 94•18 years ago
|
||
*** Bug 347119 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 95•18 years ago
|
||
This is not acceptable on the 1.8.0 branch because of the string changes, right?
Comment 96•18 years ago
|
||
(In reply to comment #95) Yes.
Comment 97•18 years ago
|
||
*** Bug 349083 has been marked as a duplicate of this bug. ***
Comment 98•18 years ago
|
||
*** 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.
Description
•