Closed Bug 332556 Opened 18 years ago Closed 18 years ago

Enhance handling installation of extensions, mostly "foreign" ones

Categories

(Toolkit :: Add-ons Manager, enhancement)

x86
Linux
enhancement
Not set
normal

Tracking

()

VERIFIED WONTFIX

People

(Reporter: omgs, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.7.11) Gecko/20050729
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.7.11) Gecko/20050729

Products capable of managing extensions like Thunderbird can't download the xpi files by themselves, so a browser like firefox or seamonkey have to be used for this "intermediate" task. It's a very common error (sometimes by new users, and sometimes even experienced users) that going to the extension page with the browser, they left click the link (or the link doesn't point to a xpi file directly). Anyway, the extension is downloaded and firefox tries to install it. Finally, there are some chances:

1) The extension is ONLY compatible with current version of firefox
2) The extension is compatible with current version of firefox AND other products
3) The extension is NOT compatible with firefox (or current version of firefox) BUT it's compatible with other products (that firefox is not aware of, nor shouldn't).
4) Surely some other



Reproducible: Always

Actual Results:  
Firefox downloads the xpi and tries to install it, regardless it's valid or not.

Expected Results:  
Firefox should ALWAYS ask (even if the extension is fully compatible with firefox) to download, before the usual installation procedure (that would be performed from the download path). The target is to have full control on the downloaded file, so it can be redristibuted (for corporate environments) or just stored so the other app can install it. What's more, I current have no idea of where firefox stores the downloaded file, that I have to download again (if I can) if I want to install in another firefox installations and/or use for another product the extension is compatible with (for instance, the calendar). Also, Firefox should be wise enough and tell the user the products the extension can be installed in, regardless failure of success. If the extension is for firefox only, then something like "this extension is not to use with more products".

This is being raised because I receive lots of questions (and see questions in forums) from users about extensions not installing in thunderbird, being the reason that firefox doesn't return proper info about the extension that the user can follow and fix.
Related to/duplicate of bug 254116 and Thunderbird bug 295462?
No, I don't think so. Maybe solving this bug in the suggested way indirectly solves the other, but solving the other bug in its suggested way (what seems not to be a way according to comments, a new extension for thunderbird extensions) could only solve a part of this bug. Besides, I stick on firefox, unlike the other, sticking on thunderbird.

I'll say that what I want is a kind of download and pre-install action (maybe post-install, too), unlike just a pre-download action.
I believe that at least in part this bug is the same as bug 313471.

For myself, as written in comment #0 this bug is wontfix. We aren't going to always download instead of install. An author has the option of serving their extension without the mimetype of application/x-xpinstall and with the mimetype of application/octet-stream to prompt the user to download already. Most sites that provide Thunderbird and extensions for apps other than Firefox provide instructions to right click / save as. This isn't to say this isn't a problem - just that I highly doubt the proposed solution would be implemented in Firefox.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
Let me say that you misunderstood the concept, and what you say is not what I'm asking for (among many other things), so I reopen the bug.

First: I don't think firefox (nor any software in this world) can install anything from a remote site without downloading it first, so what I say is to download (100% necessary), and not to lose that download. Then, if the extension is for firefox, (try to) install as usual. Besides, if the extension is intended to be used with more than one product, avoid downloading it again, and give the user the info about where the extension has been saved, along with extra info (the more precise, the better), so the lack of messages can't, in any way, lead to think that the extension is for firefox only.

If the extension is not for firefox (many cases), and if the user clicks instead of right click, firefox should give more chances than just the current (and clearly insufficient) "this extension is not compatible with firefox" and close. What I suggest is, after showing the message, and taking that it has been already downloaded, tell the user where to find it for using it with other products (and it would be wise enough to parse or dump the info about products in install.rdf, so the user can find the reason why firefox refused the action).

I think it's a firefox bug to not inform of why things fail, regardless the user chooses the wrong option when downloading. Maybe if it was not possible to develop multiproduct extensions this bug could be treated in a different manner, so blame in who allows these, but don't hide on closing bugs in such a quick way.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Oscar, there has been discussion that I have participated in on how best to solve this problem when Firefox is an app that runs on XULRunner for multiple apps. As for your proposed solution, that isn't going to happen. I'll leave this open and verify the path we discussed last time is still the path we are planning on taking to solve the actual problem.
More useful error messages? Yes, definitely, not this bug.

Fix AMO and evangelize other sites to not call installTrigger for non-Firefox addons? Yes, definitely, already filed, I think, if not its already in the head of the AMO team.

Adding extra clicks to address badly behaving websites and the vastly less common action of downloading an extension for Firefox just isn't going to happen.  Rob owns this space, and I'm totally backing him up here.

Marking WONTFIX again.  Reopening this bug again will result in your account being disabled, see https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → WONTFIX
Mike: I'm not a developer, nor have knowledge of the internals. I'm just describing the current behaviour of firefox, that's all I know. If the internal component is installtrigger or the elephant in somebody's noses that's not my problem, and if you think it fits in another category/product, reassign to the one you think is best for solving, but nobody has told me a proper reason, duplicate, link or anything that shows me an explanation why you don't feel like even trying to understand and solve. Also, make sure you understand what I'm asking and say something that fits. If you read my comment, I reopened the bug because I found the comment had nothing to do with my request. I know what I'm asking for, I don't know if I explained very well, but I don't think the comments fit on my request. Do you think it's a wrong behaviour? I don't think so.

Please be humble and if you think you misread, misunderstood or whatever, but if you stop it, give a proper and clear reason instead threatening.
Back from dinner, I think the facts are these:
I requested an enhancement, that from my point of view, was somehow misunderstood. After clearing, Robert said: "I'll leave
this open and verify the path we discussed last time is still the path we are
planning on taking to solve the actual problem", but two minutes later, Mike, with a different AND NOT RELATED argument ("More useful error messages? Yes, definitely, not this bug"), showing misreading, disauthorizes closes the bug and threats me to not take any action of his WRONG DECISION.

I don't know what admin or "respected project contributor" is expected to take actions (let me say that I've been contributing for several years to different projects), but if I have to forget all humbleness, I hesitate you can find some (even if any) more productive contributors than me in l10n area, and the thousands of hours I've dedicated to Mozilla products I think deserve that I can be called "respected project contributor". So, with this in mind, if this is marked again as wontfix WITHOUT A PROPER REASON TO MY REQUESTS, Mozilla can for sure forget about me for contributing anything else in the future.

I'm asking reasonable things, not forcing. Also, remember (it seems it's forgotten) that the target of this bug is promoting Mozilla software, not going against it.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
There have been discussions on adding better handling of xpi's after Firefox runs on XULRunner. Currently, for extensions that are targeted for apps other than Firefox the author has the ability to make Firefox display a download dialog. There are several reasons why your proposed solution won't be implemented since it adds additional steps for installing an extension on Firefox when the author can just serve the mimetype differently for the other apps case or just putting a note next to the link instructing to use right click - save as... also, keep in mind that the number of extensions that are targeted for Firefox.

Also, good bug reports focus on the problem and not the solution. If what you are asking for is better cross application handling of xpi's then I am one hundred percent behind it. If what you are proposing is we provide another dialog above and beyond the current dialogs when installing an extension and then providing the option to download the extension then I am against it. From your report it seems like the latter. There are better ways to handle this that don't add complexity and have been discussed after we get Firefox running on XULRunner.
Oscar, I don't know if I have ever seen you around bugzilla or anywhere else related to the project, so I don't know what your contributions have been.  Given that you're using an old (and known to be insecure!) version of the Mozilla Suite, I'm guessing you're not heavily involved in Firefox development.  That said, if you have that much time involved in the project, you should know how things work by now.

Just because I disagree with you doesn't mean I don't understand you.  Similarly, just because you don't understand my response doesn't mean I'm wrong.  You can always disagree, but its not up to you to overrule me.

Rob was going to leave this bug open to consider the case of installing an extension to a shared xulrunner instance, for use by other/multiple apps.  This should be split into a new bug to track that part of the solution.  That has little to do with expected results you listed:

"Firefox should ALWAYS ask (even if the extension is fully compatible with
firefox) to download, before the usual installation procedure (that would be
performed from the download path)."

I think this is a clear explanation on your part.  It happens to be something we think is unnecessary and would have a negative impact.  Forcing users to save the extension before installation isn't the user experience we want to provide.  I understand the problems you think this solves, but we feel it isn't the right way to solve them.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → VERIFIED
(In reply to comment #10)
> Oscar, I don't know if I have ever seen you around bugzilla or anywhere else
> related to the project, so I don't know what your contributions have been. 

If we only look in our limited memory and close environment, we'll find the same result for each other. But this is a useless point.

> Given that you're using an old (and known to be insecure!) version of the
> Mozilla Suite, I'm guessing you're not heavily involved in Firefox development.

Did it take you that long? If you were fond of reading carefully what you're told, you would find I said previously that I'm not a developer. And I don't know that foolish look about the browser used to file the bug, instead of looking at the RFE itself. Anyway, I don't agree Mozilla 1.7.12 in linux is insecure.


>  That said, if you have that much time involved in the project, you should know
> how things work by now.

I know, and nobody, even you, can say that the bug is not properly filed. First, you have to understand the request, and according to what you say, you have understood absolutely nothing.

> Just because I disagree with you doesn't mean I don't understand you. 
> Similarly, just because you don't understand my response doesn't mean I'm
> wrong.  You can always disagree, but its not up to you to overrule me.

You have never demonstrated with real data your understanding about the request, even with the uncomprehensible (and of course, unrelated) sentences about Mozilla above.

> Rob was going to leave this bug open to consider the case of installing an
> extension to a shared xulrunner instance, for use by other/multiple apps.  This
> should be split into a new bug to track that part of the solution.  That has
> little to do with expected results you listed:
> 
> "Firefox should ALWAYS ask (even if the extension is fully compatible with
> firefox) to download, before the usual installation procedure (that would be
> performed from the download path)."

Did you ever hear about redistribution? Do you know a different way to get it with only one download? Why don't you just make use of humbleness (wherever it is), giving the chance to be wrong, instead of assuming you're the best at guessing eveybody else's thoughts?

> I think this is a clear explanation on your part.  It happens to be something
> we think is unnecessary and would have a negative impact.  Forcing users to
> save the extension before installation isn't the user experience we want to
> provide.  I understand the problems you think this solves, but we feel it isn't
> the right way to solve them.

Do you want to be forwarded all the emails I've received and the lots of questions in the forums about that (if you know what I'm talking about)? Anyway, if you think there's a better way, just expose it or give a link about where it can be (or has been) discussed, but don't just close the bug without any reason.

I'm not going to waste any more energy on this, mostly because abuse and brute force beyond reason and discussion seem to be on your side. Of course, I fully disagree. You have refused to give me a link (though I asked to do so) where I could trace such discussion, see the reasons and, optionally, give a different opinion, so let me even hesitate it's true because I can only see your (subjective) words. You didn't even give the chance to use something democratic like votes, just exposed your (let me say, out of real world) developer point of view.

Don't worry, mozilla crusade is over for me right now. I give up. This is just the last drop overfilling the glass. Keep up the good work (if you can).
(In reply to comment #11)
> I'm not going to waste any more energy on this, mostly because abuse and brute
> force beyond reason and discussion seem to be on your side. Of course, I fully
> disagree. You have refused to give me a link (though I asked to do so) where I

If you were more involved in Firefox develoment, then you would have know it's http://wiki.mozilla.org/ . Most discussions takes place in the Wiki, not in Bugzilla.

> could trace such discussion, see the reasons and, optionally, give a different
> opinion, so let me even hesitate it's true because I can only see your
> (subjective) words. You didn't even give the chance to use something democratic
> like votes, just exposed your (let me say, out of real world) developer point
> of view.
(In reply to comment #12)
> If you were more involved in Firefox develoment, then you would have know it's
> http://wiki.mozilla.org/ . Most discussions takes place in the Wiki, not in
> Bugzilla.
I can't find anything about this particular subject on the wiki.

I only see there has been discussion about this in comment 5, but this discussion is probably not publically available somewhere.
Is this bug asking for something like the "save as..." button requested in bug 47805? I've always wanted that, but the possibility of multiple installs gets in the way.  Maybe show the button if there's only one install, otherwise disable it in the rare multi-install case?
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.