60251 - Display error, if user triggered install although disabled

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Installer: XPInstall Engine, enhancement, P3)

Description

[Ben Bucksch (:BenB)]

Reproduce:
1. Disable XPInstall (Uncheck "software installation" in prefs).
either
a2. Go to <http://www.bucksch.org/1/projects/mozilla/dist/psm>.
a3. Click on "Install".
or
b2. "Open" a local xpi file in the browser.

Actual result:
a: Nothing.
b: The throbber spins infinitely.

Requested result:
A dialog pops up, telling the user that he is about to install, but he has
disabled installation it.

I said "Requested" not "Expected" result, since I thought and many of the Beonex
users think, this option were for automatic updates only, and disable it. Then
they are surprised, why the manual software installation doesn't work.
(Especially the spinning throbber is very misleading BTW.)

If the option also enables automatic updates, it is overloaded and should be
splitted. But IMO, completely disabling manual installs (as today) doesn'T make
much sense. So, a way to fix this bug would be to make the pref apply to
automatic installs only.

Comment 1

[tenthumbs]

Personally, I have always thought that the pref meant disable all installation,
which is what it does. I most certainly want the that capability particulary in
the current situation where mozilla dialogs are sometimes very slow to appear
and where mozilla often gives no indication it is doing anything. Splitting it
into two prefs wouldn't be unreasonable. though.

FWIW, the older behavior was to do nothing at all. I spent a lot of time clicking on the
"Install PSM" button on the iPLanet site until I figured it out. :-)

Comment 2

[Ben Bucksch (:BenB)]

> FWIW, the older behavior was to do nothing at all. I spent a lot of time
> clicking on the "Install PSM" button on the iPLanet site until I figured it out.

but

> Personally, I have always thought that the pref meant disable all
> installation, which is what it does. I most certainly want the that
> capability particulary in the current situation where mozilla dialogs are
> sometimes very slow to appear

I don't understand. You were surprised that nothing happened, but you don't want
a dialog either? I and others (very clueful people) felt in the same pitfall, so
why not display a dialog?

Comment 3

[Daniel Veditz [:dveditz]]

If the site wants to be nice it can check the install capability before 
attempting to initiate one:

   if (!InstallTrigger.enabled())
      alert("you must turn on the install pref to do this");
   else
      <what's there now>

If we make turning off the pref cause a dialog to come up then it gives the 
site yet another way to annoy you into turning something on you wanted off. 
Consider the "warn on cookie" pref in Communicator 4.x -- sites simply started 
flooding people with so many cookies they were forced to turn that off and just 
accept cookies.

Eventually it'd be nice to hook this into something like the cookie manager, 
where you can disallow/allow installs from specific domains. Since there's 
already a confirm dialog before an install I'm pretty reluctant to pop up 
another one. With the current pref "on" you get to confirm whether you want 
each install; the only reason I can think of to turn that pref off is if you 
really don't want to be bothered at all.

Comment 4

[Ben Bucksch (:BenB)]

> if (!InstallTrigger.enabled())

Thanks a lot. Will build that in my scripts.

> If we make turning off the pref cause a dialog to come up then it gives the
> site yet another way to annoy you into turning something on you wanted off.
> Consider the "warn on cookie" pref in Communicator 4.x -- sites simply
> started flooding people with so many cookies they were forced to turn that off
> and just accept cookies.

You might be right. I didn't consider so much evilness.

> the only reason I can think of to turn that pref off is if you
> really don't want to be bothered at all.

BUt we do have autoupdate capability, not? How do I turn *that* off, then?

Comment 5

[Daniel Veditz [:dveditz]]

The only thing we've got is XPInstall, which can be triggered from javascript 
or by clicking on a link of the correct MIME-type.

Communicator had an "autoupdate", but it was only triggerable by your admin if 
you had installed the enterprise version with correct permissions 
pre-installed.

We talked about a "background update" long ago, but people seemed to feel it 
was too evil, but if we had done it I would have made sure it had a separate 
pref.

Comment 6

[Ben Bucksch (:BenB)]

ok, I guess, mozilla/xpinstall/res/content/SoftwareUpdate-Source-1.rdf is dead,
then.
Personally, I'd like to see automatic updates, for security fixes. Will take it
to the newsgroup.

Comment 7

[Daniel Veditz [:dveditz]]

That's what I was calling update *notifications*, and we do want to provide 
that service. Don't let me stop you from discussing it on newsgroups, however, 
because there are several forms it could take--discussion is good :-)

If that's what you meant by automatic update then there will be ways to turn 
off the notifications which will be separate from the global software 
installation preference.

Comment 8

[Matthias Versen [:Matti]]

*** Bug 204785 has been marked as a duplicate of this bug. ***

Comment 9

[Michael Kohler [:mkohler]]

This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.