Closed
Bug 567127
Opened 15 years ago
Closed 14 years ago
Add install button to the add-ons manager
Categories
(Toolkit :: Add-ons Manager, defect)
Toolkit
Add-ons Manager
Tracking
()
VERIFIED
FIXED
mozilla2.0b5
Tracking | Status | |
---|---|---|
blocking2.0 | --- | beta5+ |
People
(Reporter: mossop, Assigned: Unfocused)
References
Details
(Whiteboard: [rewrite])
Attachments
(2 files, 4 obsolete files)
(deleted),
image/png
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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•15 years ago
|
||
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•15 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•15 years ago
|
Assignee: dtownsend → nobody
Comment 3•15 years ago
|
||
Several users have also been trying File -> Open lately.
Assignee | ||
Updated•15 years ago
|
Assignee: nobody → bmcbride
Status: NEW → ASSIGNED
Assignee | ||
Comment 4•15 years ago
|
||
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)
Assignee | ||
Comment 5•15 years ago
|
||
Assignee | ||
Comment 6•15 years ago
|
||
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?
Assignee | ||
Comment 7•15 years ago
|
||
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•15 years ago
|
||
(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?
Assignee | ||
Comment 9•15 years ago
|
||
(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•15 years ago
|
||
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•15 years ago
|
||
(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•14 years ago
|
||
(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•14 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.
Comment 15•14 years ago
|
||
(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•14 years ago
|
||
(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•14 years ago
|
||
(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•14 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•14 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•14 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.
Comment 21•14 years ago
|
||
(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.
Assignee | ||
Comment 22•14 years ago
|
||
> (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•14 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.
Comment 24•14 years ago
|
||
(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•14 years ago
|
||
Does it look the same and work the same in all Mozilla apps?
Comment 26•14 years ago
|
||
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•14 years ago
|
||
From where can I download the add-ons manager.
Reporter | ||
Comment 28•14 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.
Assignee | ||
Comment 29•14 years ago
|
||
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)
Assignee | ||
Comment 30•14 years ago
|
||
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•14 years ago
|
||
Is it possible to test this by temporarily overriding the file picker component?
Assignee | ||
Comment 32•14 years ago
|
||
(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.
Assignee | ||
Comment 33•14 years ago
|
||
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)
Assignee | ||
Comment 35•14 years ago
|
||
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•14 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)
Assignee | ||
Comment 37•14 years ago
|
||
Adds a test.
Attachment #461972 -
Attachment is obsolete: true
Attachment #465082 -
Flags: review?(dtownsend)
Reporter | ||
Comment 38•14 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+
Comment 39•14 years ago
|
||
(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
Assignee | ||
Comment 40•14 years ago
|
||
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
Assignee | ||
Updated•14 years ago
|
Flags: in-testsuite- → in-testsuite+
Comment 41•14 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Reporter | ||
Updated•14 years ago
|
Target Milestone: --- → mozilla2.0b5
Comment 42•14 years ago
|
||
(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•14 years ago
|
||
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•14 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•14 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
Comment 46•14 years ago
|
||
(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•14 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•14 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•14 years ago
|
||
Thanks, Dave. I'll be looking forward to seeing that release.
Comment 50•14 years ago
|
||
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.
Assignee | ||
Comment 51•14 years ago
|
||
(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•14 years ago
|
||
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•14 years ago
|
||
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•14 years ago
|
||
So i'll digg a bit more into it tomorrow.
Comment 56•14 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•14 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.
Assignee | ||
Comment 58•14 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.
Does SeaMonkey implement the notifications added in bug 552965?
Comment 59•14 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•14 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
Comment 61•14 years ago
|
||
(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•14 years ago
|
||
(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•14 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•14 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.
Updated•14 years ago
|
Flags: in-litmus? → in-litmus?(vlad.maniac)
Updated•14 years ago
|
Attachment #462289 -
Flags: ui-review?(jboriss)
Comment 66•14 years ago
|
||
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.
Description
•