348150 - Please Default to SHOW "install" button (pref 'extensions.hideInstallButton')

Status: RESOLVED WONTFIX

(Firefox :: Settings UI, defect)

Description

[Rick Stockton]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1b1) Gecko/20060727 BonEcho/2.0b1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1b1) Gecko/20060727 BonEcho/2.0b1

Ref bug 342656: Elimination of the "install" button makes it impossible to install a theme (.jar file) from local disk. If a Firefox 2.0 User is installing from addons.mozilla.org, then there may not be a problem--

But MANY themes are maintained by their authors on private FTP sites, rather than AMO. Big Problem: After you download the *.jar file, you can't install it until AFTER you search bugzilla to see documentation for the preference within bug 342656.

(Bug has instructions for opening about:config and changing the pref, but you need to know the NAME OF THE PREF before you can proceed to change it. Bugzilla search is necessary to find the pref.)

We've dumbed it down to far-- eliminating functionality which I think many FF users depend on to install themes. There will be lots of queries at Mozillazine forums, lots of emails nagging Theme developers... and lots of time spent by users to perform the about:config change. 

I understand that a request to switch the default to 'false' (i.e., DON'T hide the "install" button) will be closed "wontfix". Therefore, I instead request that this pref be exposed in the default 'Preferences' GUI.

Unsure whether this bug should be in component "Extensions/Theme Manager" or "Preferences"... but the problem originates in a change to "Extensions/Theme Manager", so that's where I'm listing it. 

Reproducible: Always

Steps to Reproduce:
1. Download a Theme as a *.jar file.

2. Open "Tools" --> "Add Ons" --> "Themes" to install your new Theme.

3. Look for the "Install" button-- it ain't there.

4. cuss quietly... search bugzilla if you're "savvy enough", then fight your way through "about:config" or hand-edit your "prefs.js" to reset the pref as "false".
Actual Results:  
Slow painful process to (A) search bugzilla and find the name of the new pref which Erased the Button; then (b) re-show the button via editing prefs.js or diving into about:config.

Expected Results:  
The Button should be there, we need the ability to install a downloaded *.jar file (AFAIK).

If the Button won't be there, then please AT LEAST Show us the pref in the preferences GUI, or as an "option" within the Extensions Manager panel, so that we can reset it to the needed value without doing a slow search of bugzilla to see the name of the new pref which "broke" it.

I'm calling it "Minor", but the workaround is hardly "easy" for a typical User. (Uh, that's why we even HAVE a GUI for prefs, hand editing or about:config editing is NOT suitable for most end users.)

If anyone wants to vote for "Normal" Severity, I really have to agree :(

Comment 1

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

Over to Preferences since there is no work that needs to be done for this to happen in the Extensions Manager.

cc'ing beltzner

Comment 2

[Rick Stockton]

The main discussions about the new pref being a mistake are within bug 342656, from comment https://bugzilla.mozilla.org/show_bug.cgi?id=342656#c22 downwards.

Comment 3

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

(In reply to comment #2)
> The main discussions about the new pref being a mistake are within bug 342656,
> from comment https://bugzilla.mozilla.org/show_bug.cgi?id=342656#c22 downwards.
Ummm... NO! Please keep the discussion in this bug.

Comment 4

[Mike Connor [:mconnor]]

So, uh, we've never had an option to show this button in a Firefox release.  It was a hardcoded #ifdef for 1.0/1.5, so you couldn't have it at all.  Any site can trigger a theme install, just as any site can trigger an extension install.  See http://members.shaw.ca/lucx/ as an example.

Exposing UI for a less efficient and more involved installation process doesn't make sense if there's a better path that we want theme/extension authors to follow.  Drag and drop works, as does file->open in the main window, so there isn't a need to have this.

That said, exposing UI to change the pref is absolutely ludicrous, and will never happen.  Either its something we're going to show in the manager, or its not.

Comment 5

[Rick Stockton]

Per Robert's comment 3, all NEW comments should be added HERE, not in the Closed bug (I collided while making a post to that effect). 

Robert reports that "drag and drop" from Konqueror, when used as a file system browser, DOES work for him. Maybe my problem (can't drag from Krusader or Knoqueror) is uncommon, being a result from a defective build of Konq and  Krusader within Mandrake 2006.0.

I've been a 2.0.x user since pretty early on, and the button has always been present there. I think it's nice to have. 

I feel that it is a VERY BAD UI choice to make people fire up external 'File Manager' Apps, or even go to Firefox's own "File" --> "Open File..." menuitem to install a Theme: They're on the Add-Ons panel, working with Add-ons: dragging and opening files from other applications, or loading it from a completely separate browser-based "Open File" pop-up is counter-intuitive and awkward.

"File" --> "Open File..." makes sense for html files, and graphics. But installing jar files by 'opening in the browser' is cludgey. (Even ignoring the basic fact that it doesn't work on my box.)

Per Mike, I strongly agree: If we can actually put "show the button!" back on the table, that's the right answer, although maybe we should label it "install from local file" rather than just "install".

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #5)
> Per Mike, I strongly agree: If we can actually put "show the button!" back on
> the table, that's the right answer, although maybe we should label it "install
> from local file" rather than just "install".

You, uh, totally misinterpreted mconnor; he resolved this as WONTFIX. What he was saying was: we don't have this button for a reason (cf: it's not a primary usecase, and not deemed worthy of having permanent UI space for it) which implies that we also won't add a visible pref for hiding/showing the button.

I think you want to pin your hopes on bug 342655.