567127 - Add install button to the add-ons manager

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Dave Townsend [:mossop]]

Some apps aren't browsers and so need an easy way to install XPI's from disk. We used to have an install button, we should still have one for those apps that want it, the question is where to fit it in the UI.

Comment 1

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

I think it should also be possible to hide the "Search engines" category. For many xulrunner-based apps, it does not make any sense to have that category.

Comment 2

[Dave Townsend [:mossop]]

(In reply to comment #1)
> I think it should also be possible to hide the "Search engines" category. For
> many xulrunner-based apps, it does not make any sense to have that category.

I think we'll make the search engines category auto-hide when none are installed anyway

Comment 3

[[not reading bugmail]]

Several users have also been trying File -> Open lately.

Comment 4

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Attachment: WiP screenshot

Functionally, I have it working (and better than before, since it now supports selecting multiple files). 

However, I stuck the button in the first spot I saw that there was some free space. And I'm not entirely sure about the wording of the filepicker dialog (title and the filetype filter name).

Comment 5

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Attachment: WiP v1

Comment 6

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Unless I'm mistaken, there's no way of automating testing of filepicker dialogs in cases like this. The EM API is (I assume) covered by tests though.

Comment 7

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Boriss: There's also the question of what to display (if anything) when the user selects a file that isn't an Addon install.

(Sorry for the bugspam)

Comment 8

[Bill Gianopoulos [:WG9s]]

(In reply to comment #5)
> Created an attachment (id=448668) [details]
> WiP v1

IN previous version, with the old Add-ons manager, the presence of the Install button was controlled by the hidden preference extensions.hideInstallButton.  This was set to false by the applications that wanted the choice to appear.  Shouldn't this new code work the same way?

Comment 9

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #8)
> IN previous version, with the old Add-ons manager, the presence of the Install
> button was controlled by the hidden preference extensions.hideInstallButton. 
> This was set to false by the applications that wanted the choice to appear. 
> Shouldn't this new code work the same way?

I'd forgotten about that. That preference could be added in, although I'm not sure what the benefit would be. If the aim is to disallow local installs, then it would make more sense to have a pref to disable local installs entirely in the UI - which would hide the install button and disable drag&drop (bug 565682). Of course, that wouldn't block other means of doing so (such as using the API directly).

Comment 10

[Robert Strong (they/them - no direct email)]

The reason for the pref was so Firefox didn't display the button which took up UI real estate and had nothing to do with preventing local installs.

Comment 11

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(In reply to comment #10)

> The reason for the pref was so Firefox didn't display the button which took up
> UI real estate and had nothing to do with preventing local installs.

Absolutely. Please don't merge this bug and bug 565682. The pref's meaning could be extended in the future but we still need it here. The "install from file" button was removed from Firefox extension panel looooong ago and probably has nothing to do back in it.
I support entirely adding back this pref to control the button's presence or not, and xulrunner-based apps really need this fix asap.

Comment 13

[Jennifer Morrow [:Boriss] (UX)]

(In reply to comment #8)
> (In reply to comment #5)
> > Created an attachment (id=448668) [details] [details]
> > WiP v1
> 
> IN previous version, with the old Add-ons manager, the presence of the Install
> button was controlled by the hidden preference extensions.hideInstallButton. 
> This was set to false by the applications that wanted the choice to appear. 
> Shouldn't this new code work the same way?

Seems like a sensible way to do this.  Though, in addition, could we not support installing an .xpi file if it's opened via the current Open menu item?  Open/file already opens a wide range of filetypes.

Comment 14

[Dave Townsend [:mossop]]

(In reply to comment #13)
> (In reply to comment #8)
> > (In reply to comment #5)
> > > Created an attachment (id=448668) [details] [details] [details]
> > > WiP v1
> > 
> > IN previous version, with the old Add-ons manager, the presence of the Install
> > button was controlled by the hidden preference extensions.hideInstallButton. 
> > This was set to false by the applications that wanted the choice to appear. 
> > Shouldn't this new code work the same way?
> 
> Seems like a sensible way to do this.  Though, in addition, could we not
> support installing an .xpi file if it's opened via the current Open menu item? 
> Open/file already opens a wide range of filetypes.

That should already be supported.

Comment 15

[Bill Gianopoulos [:WG9s]]

(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #8)
> > > (In reply to comment #5)
> > > > Created an attachment (id=448668) [details] [details] [details] [details]
> > > > WiP v1
> > > 
> > > IN previous version, with the old Add-ons manager, the presence of the Install
> > > button was controlled by the hidden preference extensions.hideInstallButton. 
> > > This was set to false by the applications that wanted the choice to appear. 
> > > Shouldn't this new code work the same way?
> > 
> > Seems like a sensible way to do this.  Though, in addition, could we not
> > support installing an .xpi file if it's opened via the current Open menu item? 
> > Open/file already opens a wide range of filetypes.
> 
> That should already be supported.

Open/file is fine for applications that support this.  Thunderbird does not and therefore requires the Install from file option within the add-on manager window.

Comment 16

[Jennifer Morrow [:Boriss] (UX)]

(In reply to comment #4)
> Functionally, I have it working (and better than before, since it now supports
> selecting multiple files). 

How about under the "More/preferences" dropdown in the upper right?  The purpose of this is for extra/advanced options, so "Install from file..." seems a good candidate.

> And I'm not entirely sure about the wording of the filepicker dialog
> (title and the filetype filter name).

Any reason to differentiate between "Add-on install" and "Add-on?"  They're functionality equivalent.  The title of this page could be "Select add-on to install" and the filetype filter could be "Add-on name (probably ends in .xpi):"

(In reply to comment #7)
> Boriss: There's also the question of what to display (if anything) when the
> user selects a file that isn't an Addon install.

Can we disable (grey-out) files that aren't add-on installs?

Comment 17

[[not reading bugmail]]

(In reply to comment #15)

> Open/file is fine for applications that support this.  Thunderbird does not and
> therefore requires the Install from file option within the add-on manager
> window.

It would be nice if they were both consistent one way or the other.. 2 different ways of doing something between apps doesn't make sense.  I do like thunderbirds method better, file/open just seems like its for html and feels old and disconnected from AOM, etc.

Comment 18

[KitchM]

:Mossop - Please pardon me for overlooking something if it is obvious, but could you please specify the use of the term "apps"?

Thanks.

Comment 19

[Dave Townsend [:mossop]]

(In reply to comment #18)
> :Mossop - Please pardon me for overlooking something if it is obvious, but
> could you please specify the use of the term "apps"?

applications.

Comment 20

[KitchM]

Thanks, but do you mean Mozilla applications rather than applications in general?  I will assume your usage refers to full-blown programs rather than applets associated with Mozilla programs.

Thanks again.

Comment 21

[Robert Strong (they/them - no direct email)]

(In reply to comment #20)
> Thanks, but do you mean Mozilla applications rather than applications in
> general?  I will assume your usage refers to full-blown programs rather than
> applets associated with Mozilla programs.
> 
> Thanks again.
This is about adding an Install Button in the add-ons manager. The add-ons manager we are talking about is present in Mozilla based applications (e.g. Firefox, Thunderbird, SeaMonkey, Sunbird, Songbird, Instantbird, etc.) and the install button in the add-ons manager would be an option for Mozilla based applications.

Comment 22

[Blair McBride [:Unfocused] (UNAVAILABLE)]

> (In reply to comment #7)
> > Boriss: There's also the question of what to display (if anything) when the
> > user selects a file that isn't an Addon install.
> 
> Can we disable (grey-out) files that aren't add-on installs?

No. At least, not on Windows - not 100% sure about other OSes.

Comment 23

[KitchM]

Robert Strong, thanks.  

So, first, the real issue is that we just want a change to the programming of the add-ons manager program or applet.  And I think that the install button should not be an option, but should be a standard part of that applet.

Second, the add-ons manager applet should be part of all Mozilla applications as a standard item (or "feature"?), assuming that a given Mozilla app would host add-ons.

Comment 24

[Robert Strong (they/them - no direct email)]

(In reply to comment #23)
> Robert Strong, thanks.  
> 
> So, first, the real issue is that we just want a change to the programming of
> the add-ons manager program or applet.  And I think that the install button
> should not be an option, but should be a standard part of that applet.
> 
> Second, the add-ons manager applet should be part of all Mozilla applications
> as a standard item (or "feature"?), assuming that a given Mozilla app would
> host add-ons.
To put it simply, based on a preference the add-ons manager (it isn't an applet) will display an install button.

The second item you listed is already the case.

Comment 25

[KitchM]

Does it look the same and work the same in all Mozilla apps?

Comment 26

[Robert Strong (they/them - no direct email)]

Yes with the caveat that it won't display at all unless the app has the preference or the user adds / changes the preference that is used to display / hide the button and that apps can change the styling of the button.

Comment 27

[KitchM]

From where can I download the add-ons manager.

Comment 28

[Dave Townsend [:mossop]]

(In reply to comment #27)
> From where can I download the add-ons manager.

The add-ons manager is a part of Mozilla based applications such as Firefox, Thunderbird and Seamonkey. It is not a separate thing that can be downloaded.

Please if you have any further questions email me so that we can keep this bug report focused on solving the specific problem.

Comment 29

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Attachment: Patch v1

This adds "Install from file..." to the utilities menu added in bug 562622. I hooked the installs up to the web install handler - extra security, and we get error/install notifications for free.

Comment 30

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Comment on attachment 461972 [details] [diff] [review]
Patch v1

Oh, and this *does not* add a pref to hide the "Install from file..." menu item. Since its in the utilities menu now, it doesn't take up any of the primary UI space.

Comment 31

[Dave Townsend [:mossop]]

Is it possible to test this by temporarily overriding the file picker component?

Comment 32

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #31)
> Is it possible to test this by temporarily overriding the file picker
> component?

Oh, hm, maybe. Never done that before, so I always forget its a possibility. Will look into it.

Comment 33

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Attachment: Menu order

Here's where it currently fits in the menu. 

I think Check for Updates and Recent Updates will be more commonly used (thus they're at the top here), but placing Install from File breaks up the update-related items. It could also go at the top of the menu. Don't think it makes sense to put it at the bottom, right by the "please don't use me" Background Update Check toggle.

Comment 34

[Dave Townsend [:mossop]]

Needed by string freeze

Comment 35

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Really don't consider this to be blocked by bug 584330 in any way. Its accessible via the menu that's opened by the button in that bug, but that's all (and really, that big is only cosmetic).

Comment 36

[Dave Townsend [:mossop]]

Comment on attachment 461972 [details] [diff] [review]
Patch v1

Dropping review request till comment 31 has an answer

Comment 37

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Attachment: Patch v2

Adds a test.

Comment 38

[Dave Townsend [:mossop]]

Comment on attachment 465082 [details] [diff] [review]
Patch v2

>diff --git a/toolkit/locales/en-US/chrome/mozapps/extensions/extensions.properties b/toolkit/locales/en-US/chrome/mozapps/extensions/extensions.properties

>+installFromFile.dialogTitle=Select add-on to install
>+installFromFile.filterName=Add-on

I think this maybe should be "Add-ons" but I leave it up to Boriss to make the final call.

Comment 39

[Jennifer Morrow [:Boriss] (UX)]

(In reply to comment #38)
> Comment on attachment 465082 [details] [diff] [review]
> Patch v2
> 
> >diff --git a/toolkit/locales/en-US/chrome/mozapps/extensions/extensions.properties b/toolkit/locales/en-US/chrome/mozapps/extensions/extensions.properties
> 
> >+installFromFile.dialogTitle=Select add-on to install
> >+installFromFile.filterName=Add-on
> 
> I think this maybe should be "Add-ons" but I leave it up to Boriss to make the
> final call.

I'm going to recommend Add-on singular in this dialog for Firefox consistency & the most common use case

Comment 40

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Attachment: Patch v2.1 - ready for checkin

After discussion on IRC: don't move menu item to top, keep dialog title as-in, but make the filter plural. And this is now un-bitrotted.

Comment 41

[David Dahl :ddahl]

http://hg.mozilla.org/mozilla-central/rev/faea7e06f762

Comment 42

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(In reply to comment #41)

> http://hg.mozilla.org/mozilla-central/rev/faea7e06f762

Guys, thanks a million for all xulrunner-based app authors (including myself)!

Comment 43

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

I just updated my tree and rebuilt BlueGriffon with that code in. Installing an add-on does not restart the application because |Application| is undefined... Reopen?

Comment 44

[Dave Townsend [:mossop]]

(In reply to comment #43)
> I just updated my tree and rebuilt BlueGriffon with that code in. Installing an
> add-on does not restart the application because |Application| is undefined...
> Reopen?

I guess FUEL isn't automatically on in all applications? File a new bug because that will be breaking a few things, should be a straightforward fix though.

Comment 45

[Dave Townsend [:mossop]]

(In reply to comment #44)
> (In reply to comment #43)
> > I just updated my tree and rebuilt BlueGriffon with that code in. Installing an
> > add-on does not restart the application because |Application| is undefined...
> > Reopen?
> 
> I guess FUEL isn't automatically on in all applications? File a new bug because
> that will be breaking a few things, should be a straightforward fix though.

Oh I see you filed bug 589098

Comment 46

[Antoine Turmel [:GeekShadow]]

(In reply to comment #42)
> (In reply to comment #41)
> 
> > http://hg.mozilla.org/mozilla-central/rev/faea7e06f762
> 
> Guys, thanks a million for all xulrunner-based app authors (including myself)!

thanks :)

Comment 47

[KitchM]

It looks like something may be happening here, but for the rest of the world that don't speak your dialect of geek-eze, could someone please update us on the status of this bug?
Thanks.

Comment 48

[Dave Townsend [:mossop]]

(In reply to comment #47)
> It looks like something may be happening here, but for the rest of the world
> that don't speak your dialect of geek-eze, could someone please update us on
> the status of this bug?
> Thanks.

The bug is fixed and will be in the next beta release of Firefox 4.

Comment 49

[KitchM]

Thanks, Dave.  I'll be looking forward to seeing that release.

Comment 50

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Why the menu entry has been named "Install from file..." and not "Install from File..."? In the current situation we do not match the camel case used by the other menu entries.

Comment 51

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #50)
> Why the menu entry has been named "Install from file..." and not "Install from
> File..."? In the current situation we do not match the camel case used by the
> other menu entries.

Uh, didn't notice that. Filed bug 590086.

Comment 52

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Looks good with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b5pre) Gecko/20100824 Minefield/4.0b5pre

Ludo, can you please verify the install button for Thunderbird? I would like to know if everything works for other applications. Please mark it as verified then. Thanks.

Comment 53

[Ludovic Hirlimann [:Usul]]

Doesn't seem to work for new add-on install on TB - but no error messages nor anythting in the Error console. Ain't sure its due to the fact or not that the add-on was incompatible with my shredder version.

Comment 54

[Ludovic Hirlimann [:Usul]]

So i'll digg a bit more into it tomorrow.

Comment 55

[Ludovic Hirlimann [:Usul]]

Compatible addons do get installeD.

Comment 56

[Joachim Otahal]

Seamonkey 2.1 win32 nightly/2010-08-25-02-comm-central-trunk

"Install from file..." works when installing Lightning 3.2, but fails on other add on's like http://www.mousegestures.org/dev/nightly/ without telling why. If the reason is e.g. "not compatible with" it should say so, but nothing happens when selecting it to install.

Reopen or new bug?

Comment 57

[Dave Townsend [:mossop]]

(In reply to comment #56)
> Seamonkey 2.1 win32 nightly/2010-08-25-02-comm-central-trunk
> 
> "Install from file..." works when installing Lightning 3.2, but fails on other
> add on's like http://www.mousegestures.org/dev/nightly/ without telling why. If
> the reason is e.g. "not compatible with" it should say so, but nothing happens
> when selecting it to install.
> 
> Reopen or new bug?

New bug please.

Comment 58

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to comment #56)
> Seamonkey 2.1 win32 nightly/2010-08-25-02-comm-central-trunk
> 
> "Install from file..." works when installing Lightning 3.2, but fails on other
> add on's like http://www.mousegestures.org/dev/nightly/ without telling why. If
> the reason is e.g. "not compatible with" it should say so, but nothing happens
> when selecting it to install.

Does SeaMonkey implement the notifications added in bug 552965?

Comment 59

[Joachim Otahal]

For "not compatible 'cause install.rdf want's a different verson" it behaves the same as install from file, no message.
I haven't seen any other errors for years, so I have no testcase.

I *guess* they are implemented since SM syncs code with FF/TB pretty fast, just like this bug. Fixed just a few days ago and already in SM nightly trunk.

Comment 60

[Dave Townsend [:mossop]]

(In reply to comment #58)
> (In reply to comment #56)
> > Seamonkey 2.1 win32 nightly/2010-08-25-02-comm-central-trunk
> > 
> > "Install from file..." works when installing Lightning 3.2, but fails on other
> > add on's like http://www.mousegestures.org/dev/nightly/ without telling why. If
> > the reason is e.g. "not compatible with" it should say so, but nothing happens
> > when selecting it to install.
> 
> Does SeaMonkey implement the notifications added in bug 552965?

No not yet, bug 581974

Comment 61

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #60)
> > Does SeaMonkey implement the notifications added in bug 552965?
> 
> No not yet, bug 581974

Means we also need a separate bug for Thunderbird then? As Ludovic pointed out he also doesn't see a notification with the latest trunk build.

Comment 62

[Mark Banner (:standard8)]

(In reply to comment #61)
> (In reply to comment #60)
> > > Does SeaMonkey implement the notifications added in bug 552965?
> > 
> > No not yet, bug 581974
> 
> Means we also need a separate bug for Thunderbird then? As Ludovic pointed out
> he also doesn't see a notification with the latest trunk build.

No need for new bug, bug 571759 will cover the general add-on manager fix ups that Thunderbird needs.

Comment 63

[KitchM]

Oops.  I seem to have misunderstood something.  Let me see if I get this right.

1. The "add-ons manager" is a little applet that is automatically added to any Mozilla application that uses add-ons or themes or plugins.
2. It is the same applet in all programs.

Then I'm confused as to why it would be different in any application?  Wouldn't the layout and button choices be the exact same thing?

As of this point in time, when a user selects one or more add-on files to install, it goes to the "Installation" tab and leaves the user there without a way to install more (because there is no "Install" button).

This seems to imply a non-intuitive install procedure.

Comment 64

[Dave Townsend [:mossop]]

(In reply to comment #63)
> Oops.  I seem to have misunderstood something.  Let me see if I get this right.
> 
> 1. The "add-ons manager" is a little applet that is automatically added to any
> Mozilla application that uses add-ons or themes or plugins.
> 2. It is the same applet in all programs.

It is UI built into the application.

> Then I'm confused as to why it would be different in any application?  Wouldn't
> the layout and button choices be the exact same thing?

Some pieces of UI may not be relevent in some types of applications.

> As of this point in time, when a user selects one or more add-on files to
> install, it goes to the "Installation" tab and leaves the user there without a
> way to install more (because there is no "Install" button).

Please file a new bug if you are seeing issues and if you have further questions please email me, bugs aren't the best place to ask questions about how Mozilla applications to work.

Comment 66

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Manual test covered by:
https://litmus.mozilla.org/show_test.cgi?id=15218