The "Install" button at the bottom left of the Add-ons manager allows a user to install a XPI file from their local disk. This is a pretty rare action; the primary mechanism for getting Add-ons will be through addons.mozilla.org or other websites. I'm concerned that most users new to Add-ons will presume that the best way to install an add-on will be through the "Install" button. It should be removed to avoid confusion. (See bug 342655 for what I think we should eventually be replacing this with)

I'm not sure how this slipped in, but this was for non-browser apps only since the EM was implemented. Need a pref (extensions.hideInstallButton) to dynamically remove the Install button if true (default false/not present, default true for Firefox)

The toolkit should default to showing the button and should hide the button if the network.protocol-handler.expose* prefs show http/https as exposed protocols (which is the case for browser-like apps).

bsmedburg's approach seems to be the better one. network.protocol-handler.expose.http(s) doesn't seem to be defined by any app, but network.protocol-handler.expose-all appears to be defined in all browsers. This patch checks network.protocol-handler.expose-all and removes the install button if it is set to true.

We should probably check both prefs (expose.http overrides expose-all).

The install button is for local files and it is also possible to use http(s) in the file name box from other apps (it just downloads it and then uses the local path it downloaded to)... am I missing something? Also, there have been several requests to add this button to Firefox. How about just using mconnor's approach so it is easy to override?

And make the default what, shown or hidden?

I'd prefer it to be a default of show since most apps using toolkit would use it

(In reply to comment #7) > I'd prefer it to be a default of show since most apps using toolkit would use > it What's the point if it defaults to show? The idea was to eliminate that button since it would confuse users. WONTFIX seems to be more appropriate if we want to leave the install button in by default.

I found a stray alert in the file that is also removed by this patch

(In reply to comment #8) > What's the point if it defaults to show? The idea was to eliminate that button > since it would confuse users. WONTFIX seems to be more appropriate if we want > to leave the install button in by default. Toolkit needs to support more than just browser and when using an app that isn't a browser the usual install process that is used is to download the xpi and install it locally. Once we get the apps running on top of XULRunner, have standard install locations, etc. a more elegant solution can be created.

I forgot to mention that by default what is meant is if the pref is not present. This will make it so other apps get it by default which isn't so much a problem with our apps but for apps that we don't have in our tree.

Oh, nevermind, I thought you were saying the browser should keep the install button visible by default. I don't see any compelling reason to add an install button to the extensions manager due to the availability of file->open file. What reasons have users given for having an install button in the addons manager in firefox? Why is that better than file->open file? Having a specific pref override for this button doesn't seem necessary since we should be able to detect browser applications accurately, and sane browsers should have a mechanism for choosing a local file to open.

Themes

(In reply to comment #13) > Why is that better than file->open file? "It's much easier to discover in the Addons manager" is one reason.

Checked in to trunk

Comment on attachment 227042 [details] [diff] [review] patch A simple patch that allows Firefox and other toolkit apps to optionally remove the Install button from the add-ons mgr

cause this ? http://forums.mozillazine.org/viewtopic.php?p=2341717#2341717

no, that is bug 342813

(In reply to comment #19) > no, that is bug 342813 > thanks.

Checked in to MOZILLA_1_8_BRANCH for Firefox 2.0

Removing the "Install" button was a bad decision IMO. It's much more logical to click "install" in the Add-ons manager than in the "file" menu (where you can open a website and other file types too). You uninstall, activate and disable extensions and themes in the Add-ons manager. So, it should be possible to install it too.

just an fyi: it is only removed in Firefox and can be added back by changing the extensions.hideInstallButton to false.

Wow, I just WASTED 15 minutes finding this newly-created bug: I simply want to install a new "theme" .jar file which I have downloaded from a site **OTHER** than addons.mozdev.org FYI there are A LOT of themes and Extensions which are only offered on Developers' private web sites, which MUST be installed this way. Also, there are LOTS of Developers who put put most Updated versions only on their local Sites, because they have complex forum environments which mozdev can't support. Thus, the basic concept "This is a pretty rare action" IS TOTALLY WRONG. If I try file --> open with a .jar file, my only options are "save" and "cancel". Maybe I need to hand-edit mimeTypes.rdf. If so, that's a THRILLING PROSPECT for "non-techie" users. The prospect of "simply" hand-editing prefs.js to add user_pref("extensions.hideInstallButton", false); while remembering that it must be done while Firefox is NOT running, seems a similarly thrilling prospect. This was a terrible idea-- but only Mike understood/assumed the installation of downloaded .xpi and .jar files to be a "rare action". Please re-open this bug (or open a new one, if that's the correct procedure) to pull this patch.

(In reply to comment #24) Fix typos for more clarity > while remembering that it must be done while Firefox is NOT running, seems a > similarly thrilling prospect. (edit: for TYPICAL users.) > > This was a terrible idea-- but only Mike understood/assumed the > installation of downloaded .xpi and .jar files to be a "rare action". > > edit: but only BECAUSE Mike understood/assumed.... Thanks, Rick

More thorough instructions to re-enable: type about:config in the url/address bar type hideInstallButton in the filter box Select the extensions.hideInstallButton entry and either right click -> toddle or double click it so it displays false for the value. note 1: this must be done with the app running and does not require restarting the app though you will have to re-open the Add-ons Manager if it is already open for the install button to display. note 2: you can also drag and drop onto the Add-ons Manager to initiate an install of a theme or extension. note 3: this bug should not be reopened and if you think the button should be displayed by default please open a new bug though I highly suspect it will be wontfix'd. note to self: get an extension manager bugzilla component added to toolkit

Thanks Robert, my new theme is happily installed. But I think we must agree, a Firefox user must first find this bug and learn that the pref is "hideInstallButton" in order to EITHER type it into about:config or hand-edit prefs.js (which I had already done). Because I didn't understand exactly what sort of "Drag and Drop" you meant, I tried doing a file-open, selecting the .jar file in the GTK filechooser, and dragging from there into the Add-ons manager window. My Computer froze (Mandrake 2006), with the mouse pointer looking weird. Still movable, but not functional anywhere on the desktop. I guess you mean some OTHER kind of "drag and drop", like from a Firefox-displayed web page with links? Per your suggestion, I will open another bug, not asking that the default be changed, but that the pref be exposed in the regular "preferences" GUI and not be so hard to track down.

Rick, the chances of that pref. getting into visible UI are about as slim as a pancake after an 18-wheeler's run over it.

drag and drop a file from the filesystem onto the add-ons mgr.

(In reply to comment #29) > drag and drop a file from the filesystem onto the add-ons mgr. > Per above, the 'filesystem' I tried to use within Firefox (which is a GTK filechooser() ) froze the computer rock-solid. Is Firefox gonna understand a "drag" from Krusader, or Konqueror (!?!?!). Them's my GUI file managers. I ain't on Windoze, but maybe I don't understand what you're saying to do.

Try it from your file manager and as long as it has implemented GTK DnD it should work... does for me with several file managers

"as long as it has implemented GTK DnD it should work" <ballistic, but with respect> Well, Nautilus would work, *IF I HAD GNOME*. (And Since gtkFileChooser(), as provided within Firefox DOESN'T IMPLEMENT THIS CAPABILITY.) So we do have some alternatives: (a) you fight with the lords of GTK to enhance the filechooser. Heck, I *GAVE THEM * code to show and sort by filesize (even Microsoft Explorer shows a filesize column), plus another codeset to show the full time-of-day for the "last modified date" column. In the bugs, these were supported by other users... in fact, I provided the code for an *EXISTING* RFE bug. The lords of GTK didn't enhance it. Good Luck. (b) I'd actually love this alternative: REPLACE the use of GtkFileChooser() in all Mozilla.org products with the *FAR SUPERIOR* Nautilus UI. TKFileFirefox/Thunderbird/Sunbird/Seamonkey use of the brain-damaged "gtkFileChooser (b) Mozilla.org can announce that they depend on GNOME-- kubuntu users, and many users of other KDE-based distros (especially in Europe), and everyone else who uses a "thin" DM shouldn't bother to attempt using Firefox. (KDE apps such as Krusader and Konqueror aren't built with required Gnome dependencies; those EVIL NO GOOD KDE Developers!). (c) you could bring back the button, or ask the UI people to drop it into the "Preferences" --> "Advanced" --> Update " panel. (I'm not recommending that alternative, just mentioning it.) (d) you could have Firefox 2.0 incorporate (and break) Mr. Tech's Local Install extension, in the same manner that the "highlight" New UI Feature of Firefox 2.0 is an inferior rip-off of tab-mix-plus. </ballistic> I went ballistic due to my _somewhat unsatisfactory_ experience with Gnome gtkFileChooser() bug management. But really, if you're gonna REQUIRE Nautilus for Linux Users to install a Theme, that sukz. BTW, if I Google for "gnome file manager" the first sentence which appears is from the old Project Home page, it proclaims Nautilus to be: "A next-generation file manager for GNOME, akin to KDE's Konqueror." I think that we should respect KDE Desktop User's choice to use the ORIGINAL "next-generation" file manager, and have an easy way for Users to Install a .jar file on these platforms. Remember, kubuntu is especially popular among exactly those newbies who can't be expected to search mozilla bugzilla in order to find this pref. I know that you have huge resistance to UN-DO good work which you just did. But the basic premise in the Description, "This is a pretty rare action..." that Themes are almost always gotten from aom, is untrue. Heck, even such an important Theme Developer as Alfred Kaiser doesn't keep aom fully up-to-date. Again, please take my tone as intended-- theatrical emphasis, NOT personal attack. Now that the button has DISAPPEARED, I'm with those other folks in comment 5-- I want that button, because the workarounds are NASTY.

I'm with Thomas, comment 22: even going to the "File" --> "Open File..." BROWSER menu is bad UI for managing installation of a Theme.

If the "confusion" was that people were pressing "install" when they really wanted to go to AMO, is there enough room to re-label the button as "install local file"? (Looking at my own PC isn't a trustworthy guide for this question, I'm 1400x1050 with non-standard fonts on a 21" screen.)

Please take your rants about the file chooser, etc. elsewhere... this is the extension / theme manager component and has absolutely nothing to do with the file chooser implemented in the application or gtk. The Firefox ui people are the ones that requested this... I am the extension manager module owner and personally prefer having the install button which is why it is on by default and the app has to explicitly hide it by setting a pref... this is why it is available in Thunderbird, Sunbird and XULRunner apps that use the extension manager by default. I just performed a DnD install on one extension and one theme from my file system using Konqueror and it worked without a problem... it should work with most linux file managers as I stated earlier. Please take your comments to bug 348150 - this bug is done with.

Willco! (Thanks for posting my bug #, I was just putting it in as we collided.)