The default bug view has changed. See this FAQ.

Add install button to the add-ons manager

VERIFIED FIXED in mozilla2.0b5

Status

()

Toolkit
Add-ons Manager
VERIFIED FIXED
7 years ago
6 years ago

People

(Reporter: mossop, Assigned: Unfocused)

Tracking

Trunk
mozilla2.0b5
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +
in-litmus +

Firefox Tracking Flags

(blocking2.0 beta5+)

Details

(Whiteboard: [rewrite])

Attachments

(2 attachments, 4 obsolete attachments)

(Reporter)

Description

7 years ago
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.
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.
(Reporter)

Comment 2

7 years ago
(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
(Reporter)

Updated

7 years ago
Assignee: dtownsend → nobody

Updated

7 years ago
Blocks: 567640
Several users have also been trying File -> Open lately.
Assignee: nobody → bmcbride
Status: NEW → ASSIGNED
Created attachment 448666 [details]
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).
Attachment #448666 - Flags: feedback?(jboriss)
Created attachment 448668 [details] [diff] [review]
WiP v1
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.
Flags: in-testsuite-
Flags: in-litmus?
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)
(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?
(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).
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.
(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.
Duplicate of this bug: 570513
(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.
(Reporter)

Comment 14

7 years ago
(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.
(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.
(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?
(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

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

Thanks.
(Reporter)

Comment 19

7 years ago
(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

7 years ago
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.
(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.
> (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

7 years ago
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.
(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

7 years ago
Does it look the same and work the same in all Mozilla apps?
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

7 years ago
From where can I download the add-ons manager.
(Reporter)

Comment 28

7 years ago
(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.
Created attachment 461972 [details] [diff] [review]
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.
Attachment #448666 - Attachment is obsolete: true
Attachment #448668 - Attachment is obsolete: true
Attachment #461972 - Flags: review?(dtownsend)
Attachment #448666 - Flags: feedback?(jboriss)
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.
(Reporter)

Comment 31

7 years ago
Is it possible to test this by temporarily overriding the file picker component?
(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.
Created attachment 462289 [details]
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.
Attachment #462289 - Flags: ui-review?(jboriss)
Depends on: 584330
(Reporter)

Comment 34

7 years ago
Needed by string freeze
blocking2.0: final+ → beta5+
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).
No longer depends on: 584330
(Reporter)

Comment 36

7 years ago
Comment on attachment 461972 [details] [diff] [review]
Patch v1

Dropping review request till comment 31 has an answer
Attachment #461972 - Flags: review?(dtownsend)
Created attachment 465082 [details] [diff] [review]
Patch v2

Adds a test.
Attachment #461972 - Attachment is obsolete: true
Attachment #465082 - Flags: review?(dtownsend)
(Reporter)

Comment 38

7 years ago
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.
Attachment #465082 - Flags: review?(dtownsend) → review+
(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
Created attachment 467577 [details] [diff] [review]
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.
Attachment #465082 - Attachment is obsolete: true
Flags: in-testsuite- → in-testsuite+

Comment 41

7 years ago
http://hg.mozilla.org/mozilla-central/rev/faea7e06f762
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
(Reporter)

Updated

7 years ago
Target Milestone: --- → mozilla2.0b5
(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)!
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?
(Reporter)

Comment 44

7 years ago
(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.
(Reporter)

Comment 45

7 years ago
(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
(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

7 years ago
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.
(Reporter)

Comment 48

7 years ago
(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

7 years ago
Thanks, Dave.  I'll be looking forward to seeing that release.
Blocks: 589098
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.
No longer blocks: 589098
(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.
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.
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.
So i'll digg a bit more into it tomorrow.
Compatible addons do get installeD.
Status: RESOLVED → VERIFIED

Comment 56

7 years ago
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?
(Reporter)

Comment 57

7 years ago
(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.
(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

7 years ago
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.
(Reporter)

Comment 60

7 years ago
(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
(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.
Depends on: 591851
(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

7 years ago
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.
(Reporter)

Comment 64

7 years ago
(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.
Depends on: 608820
Flags: in-litmus? → in-litmus?(vlad.maniac)

Updated

6 years ago
Attachment #462289 - Flags: ui-review?(jboriss)
Duplicate of this bug: 567640
Manual test covered by:
https://litmus.mozilla.org/show_test.cgi?id=15218
Flags: in-litmus?(vlad.maniac) → in-litmus+
Keywords: uiwanted
You need to log in before you can comment on or make changes to this bug.