Capability to require agreement to EULA, etc. before user installs



Core Graveyard
Installer: XPInstall Engine
13 years ago
2 years ago


(Reporter: Duke Fan, Unassigned)


Bug Flags:
blocking1.8b3 -
blocking1.8b5 -
blocking1.8.1 -

Firefox Tracking Flags

(Not tracked)




13 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; yie6; YPC 3.0.0; Infowalker v1.01; .NET CLR 1.1.4322)
Build Identifier: 

we'd like to list extensions for Mozilla and Firefox, but need to display a 
EULA before users installs. is there support for this? can we link to a web 
page instead of the XPI file? i'm assuming other companies have the same issue?

Reproducible: Always

Steps to Reproduce:
1. click a link to install Extension
2. extension downloads, but no opportunity in install flow to display EULA for 
user acceptance
Actual Results:  
no opportunity to display EULA for user acceptance

Expected Results:  
display a EULA before install. if user disagrees, then cancel the install.


13 years ago
Component: Listings → Extension/Theme Manager
Product: Update → Firefox
Target Milestone: 1.0 → ---

Comment 1

13 years ago
Is this a question about

Comment 2

13 years ago
yes. this is a question about

can we list an extension using an html URL?

if we have to list the URL to the XPI, how can we display
an End User License Agreement?



Comment 3

13 years ago
I'm afraid it is not possible to display an EULA during an installation of a
package compatible with Firefox 1.0/Thunderbird 1.0 extension managers.

So I think it can only be solved by linking to HTML page or putting EULA on
extension's page at u.m.o. Moving back to Update product.
Component: Extension/Theme Manager → Listings
Ever confirmed: true
OS: Windows XP → All
Product: Firefox → Update
Hardware: PC → All

Comment 4

13 years ago
To answer your question:
Update is not designed to support linking directly to html documents. Its
designed to link to XPIs and JARs directly. (The Javascript calls used for the
install links are explictly for Mozilla/Firefox's XPInstall.) It does not
support, at this time, inserting an EULA in the middle of this process.

Bouncing bug to the correct component.
Assignee: nobody → psychoticwolf
Component: Listings → Administration

Comment 5

13 years ago
I thought this would be a Extension Manager issue, displaying an EULA during the
install process.

Comment 6

13 years ago
Nor do I think it is appropriate for UMO to redirect to a non URL. 
It would be possible to have an interstitial on the website if an EULA is included.
Summary: we'd like to list extensions for Firefox, but need a way to display EULA before user installs → Display EULA before user installs
However it happens, we *do* need the ability to display a EULA, if only our own.
Agreed w/comment 4 and 5, the EULA should be hosted by us somehow and not
remote. Either part of the package and handled by the client (comment 5) or
uploaded along with the package.


13 years ago
Assignee: psychoticwolf → nobody
This is most appropriate as an XPInstall feature, so that no matter how the
package is obtained the EULA is shown. If it's done as merely an feature then it wouldn't get seen by anyone digging around
directly on the ftp servers for the install.

The down side is that the EULA wouldn't be shown before the download, but that's
actually standard behavior for binary installs like Java, Adobe Reader, etc. and
those are much, much larger than Firefox extensions.

Assignee: nobody → dveditz
Severity: normal → enhancement
Component: Administration → Installer: XPInstall Engine
Product: Update → Core
Target Milestone: --- → mozilla1.8beta
Version: unspecified → Trunk

Comment 10

13 years ago
just to clarify - this bug is still about creating a mechanism for an extension
to display a EULA (either built into the xpi or from a URL) if the xpi creators
needs to do so.

is that correct?

Comment 11

12 years ago
How does PFS handle this?  This would allow us to satisfy the MPL/GPL because
the authors could document where to find the source in that license agreement.
Flags: blocking1.8b3?


12 years ago
Flags: blocking1.8b4?
Flags: blocking1.8b3?
Flags: blocking1.8b3-

Comment 12

12 years ago
alan - what's PFS?

the more I run into the problem, the bigger it becomes.  I don't suppose there's
anyone on the cc list with time to look at this?

Comment 13

12 years ago
Plugin Finder


12 years ago
Assignee: dveditz → rob_strong
QA Contact: mozilla.update → benjamin

Comment 14

12 years ago
Not a blocker, there are more important EM features to deal with first
(dependencies and multi-extension installs).
Flags: blocking1.8b4? → blocking1.8b4-

Comment 15

12 years ago
not to mention handling global extensions more happily...

with the new schedule and version #, any chance of this getting into 1.5?

Comment 16

12 years ago
No. We're already in string freeze and a feature like this is too much for 1.5.

Comment 17

12 years ago
My understanding is that hooks for this have already been added as part of the
extension manager work done earlier in this development cycle.  Or am I
mistaken? Was that for software update only?  beng, can you shed some light here?  

There is no support for this currently for Extensions, only for Software
Updates. It should be fairly trivial to write code in the extension though that
asks once and then uninstalls if the user declines, or on the distribution page
(see to show a message prior to installation. 

Comment 19

12 years ago
> asks once and then uninstalls if the user declines
The question should be  before it installs.  We don't want things to happen
without the user's approval.

Comment 20

12 years ago
yes, installing software before the user agrees to the EULA makes the EULA more
or less useless.  so the EULA and agreement has to happen before any changes are
made to the profile.


12 years ago
Flags: blocking-aviary2.0?

Comment 21

12 years ago
any chance of getting this into the extension mgr redesign for 2.0?

easier distribution drives more commercial development of extensions which drives broader firefox adoption...
Provisionally putting this on the core blocking list, since this is growing increasingly important to extension developers.
Flags: blocking-firefox2? → blocking1.8.1+

Comment 23

12 years ago
To the best of my knowledge, EULAs are not legally binding in the U.S. (maybe even less so in other countries), modulo adoptions of UCITA, and I submit that mozilla should not promote their use. So I suggest this be marked WONTFIX.


Comment 24

12 years ago
you might want to talk to your lawyer, and a US judge, before you make sweeping, and incorrect, statements like that.

Comment 25

12 years ago
I think the discussion is wrongly headed by focussing about describing this feature as the display of an EULA.

It's just about including in the XPI a text that the author think the user should read and approve before he install the software.
And that's a useful feature for a lot of XPI. 
This is also a feature that would enable to make it much harder to push someone to install an XPI without knowing in advance what this XPI does, and they are some security risks associated with that.

The ideal implementation would be to do the same as what is done today for the signature, that is put that text inside the META-INF directory, require it to be at the start of the XPI compressed file so that it's possible to download and display it ahead of the download of the rest of the XPI. 

We could BTW include the possibility to put a short description that appears in the download dialog, but that the user doesn't have to approve separatly.

Comment 26

12 years ago
(In reply to comment #25)
> I think the discussion is wrongly headed by focussing about describing this
> feature as the display of an EULA.
> It's just about including in the XPI a text that the author think the user
> should read and approve before he install the software.

And what if the user doesn't approve? No, this feature is about EULAs.

(In reply to comment #24)
> you might want to talk to your lawyer, and a US judge, before you make
> sweeping, and incorrect, statements like that.

Ok, it seems you're mostly-corrected: says EULAs have been upheld several times. Still, they may not be legally binding elsewhere, and regardless of this, Mozilla shouldn't promote their use IMHO. How about providing a "diregard EULA as much as applicable law allows" button, at the very least?
I talked with dveditz about how best to accomplish this and I won't be able to do this for the foreseeable future.
Assignee: robert.bugzilla → xpi-engine
QA Contact: benjamin
Target Milestone: mozilla1.8beta1 → ---

Comment 28

12 years ago
(In reply to comment #25)
> It's just about including in the XPI a text that the author think the user
> should read and approve before he install the software.

Is Plain Text enough, or do we want to display HTML too? (maybe even with Images included?)

The idea is: some extentions are somewhat hard to find once installed and this page could display a short "HowTo Use me" page.

the EULA guys probably want to apply formating too.

(do we want more than one page (e.g. Info and EULA), or just one?)

Comment 29

11 years ago
This is something that can be worked around by the extension author.  You can easily construct a first-run dialog.  Look for a preference and if not set, then put up your EULA in a dialog, and then set the preference.  That way, your dialog will only be shown to the user once after post-install.  You could also show the EULA on a website before granting access to the XPI download.

Moreover, without a patch or interest from some developer, it doesn't seem likely that any patch will appear in the FF2 timeframe.  Not blocking for 1.8.1
Flags: blocking1.8.1+ → blocking1.8.1-

Comment 30

11 years ago
see comment 20 - EULA has to be displayed before the extension is installed to be effective.
Using a first-run dialog means the target xpi file was already installed, defeating the purpose of a pre-install agreement.  See comments #19 and #20.  Also, showing the information via a website prior to download might be a workable alternative, but it doesn't work for (unless you're given the same exemption that Google has) and listing there is critical for most extensions.  Also, as mentioned in comment #9, decoupling the displayed agreement/information from the .xpi doesn't work if the xpi file can be referenced directly & installed from virtually anywhere.

I've tried displaying a custom (scrolling) dialog via install.js just before installing the xpi, but found that the super-restrictive install environment scope doesn't appear to permit the openDialog command, even when trying to invoke the method from an existing window.  I also read somewhere that no longer accepts extensions with only the install.js script -- and since the presence of an install.rdf file cancels out use of the install.js file, it was yet another dead-end.

One option is to embed the xpi as a file within a separate 'installer' xpi.  Thus, the actual xpi file (the payload) would only be installed if the user accepts/acknowleges the displayed info.  On acceptance, the installer would load the real xpi file directly (by setting the location bar to the URI of the local xpi file in the installer's extension directory) and then would automatically uninstall itself.  The downside to this double-wrapped approach is that FF must be restarted twice, once for the installer then again after the real xpi file is installed.  Such an approach might become commonplace if a generic 'XPI-installer' extension were created for anyone to use by simply adding their own xpi file within it, along with any agreement/information text they wanted to display prior to installation of the payload xpi file.

...but it certainly would be better to implement a new 'preinstallURL' fact in the install.rdf file that would display the specified url page prior to install - similar to right-clicking the "Visit Home Page" option in the Extensions dialog.
For display-before-install from AMO, I have filed 342973.

It is categorically untrue that a EULA needs, by its EULA nature, to be agreed to before installation.  In fact, many EULAs bind the _user_ of the software, and not the _installer_ of the software (such that each user of a single computer has to agree to it -- see also preinstallation by OEMs), which might explain why they're not called "EILAs".  That said, _this_ bug is about before-install.  If we need some unified facility for "on first use", that's another bug.

This bug is not the place for anti-EULA activism, nor for pro-EULA activism for that matter.  This is about the facility for an extension to require that a user agree to something before they install (possibly a privacy policy, esp. for EU/safe-harbour jurisdictions).  LiveJournal still has room for more accounts, if you have some angst that you need to express. :)
Summary: Display EULA before user installs → Capability to require agreement to EULA, etc. before user installs
*** Bug 364308 has been marked as a duplicate of this bug. ***
Assignee: xpi-engine → nobody
QA Contact: xpi-engine


2 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.