246754 - InstallTrigger links don't work with HTTP redirects

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Installer: XPInstall Engine, defect)

Description

[Keith Lea]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040608 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040608 Firefox/0.8

WHen I try to download the Qute theme on
http://update.mozilla.org/themes/moreinfo.php?application=firefox&id=7&vid=8
Firefox asks if I want to open the file with "jarfile" and no option to install
the theme pops up. I'm using Firefox 0.9RC on Windows XP SP1.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[belbo]

I see the same problem with
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040614 Firefox/0.9

When I tried do install Qute I got the normal download dialog. It happened with
another theme too, but I can't remember which one, and update.mozilla.org is
down at the moment. 
There is a discussion on the mozillazine forums too at
http://forums.mozillazine.org/viewtopic.php?t=84815&sid=3c12d63c00cf160e5e52d520e23fb134
so I think this bug should be set to NEW.

Comment 2

[James Ross]

This is because you need to use InstallTrigger to install themes from a website,
which UMO doesn't do. e.g.:

InstallTrigger.installChrome(InstallTrigger.SKIN, "full url", "theme name");

Comment 3

[alanjstr]

InstallTrigger should probably be used for XPIs, too.

Comment 4

[Wolf [:wolf]]

Causing major problems for Linux/Mac users trying to get themes... 

Comment 5

[alanjstr]

Not really blocking anything.

Comment 6

[Wolf [:wolf]]

Fixed posted to the site.
Themes now use installTrigger everywhere in /themes/, with a link to download
them (right-click/save as...) on the more-info page.

Comment 7

[Tim Meader]

Please reopen... the themes don't install correctly on 0.9 official, even with
this fix.

They ask if you want to install them, but then after after downloading briefly
show up in the Theme Manager and then immediately disappear again. This is with
a fresh install, trying to download both Qute and Doodle Classic. Going directly
to Doodle's site and using the link there works fine. Unfortunately the Qute
author now simply links back to U.M.O, where it doesn't work.

Comment 8

[Tim Meader]

Same behavior is exhibited for "Mostly Crystal".

Anyone else confirm?

Comment 9

[Michael Lefevre]

Kind of a separate issue, but I guess we can morph this bug a little.

It seems to be that a link to a .jar works ok, but UMO's HTTP 302 redirection
causes things to break. I don't know if that's a Firefox issue or a UMO issue
really, but it's definitely broken somewhere. I wonder if it'd be possible to
have UMO link directly rather than redirecting through another script?

Comment 10

[James Ross]

XPInstall seems to use NS_OpenURI and a nsIStreamListener to pull the data for
the install. Something seems to be failing when the URI gives a redirect.

I've had a look as it, and don't see what's wrong, as it just uses a perfectly
normal HTTP Channel as far as I can see, which copes with the redirect all by
itself.

The really odd bit is that it *does* download (or at least pretends to) the
file, but doesn't know it's a theme install afterwards.

Comment 11

[James Ross]

Attachment: NSPR HTTP log

I don't know if this is actually useful, but Darin suggested making it. This is
a NSPR log of nsHttp:5 and nsSocketTransport:5 for me opening FF, doing to UMO,
trying to install a theme, and closing it.

Comment 12

[Tim Meader]

If it's URI related (not the redirect itself), then mod_rewrite should be able
to help out in that case.

If it's the redirect, please ignore this "help" from me. ;)

Comment 13

[James Ross]

(In reply to comment #12)
> If it's URI related (not the redirect itself), then mod_rewrite should be able
> to help out in that case.

I'm resonably sure it's the redirect, since doing InstallTrigger myself with the
actual jar URL works fine. However you do bring up a good point, perhaps it's
the orignal URI that's causing the problem (e.g. it's mime-type?), not the
redirect itself?

Comment 14

[Wolf [:wolf]]

I've tried doing a pass-through type arrangement with PHP where it passes the
file contents instead of redirecting, which also fails..

HTTP Status Code: HTTP/1.1 200 OK
Date:	Tue, 15 Jun 2004 20:54:07 GMT
Server:	Apache/2.0.49 (Win32) PHP/4.3.7
X-Powered-By:	PHP/4.3.7
Connection:	close
Transfer-Encoding:	chunked
Content-Type:	application/x-java-archive

which makes little sense to me.. 

Comment 15

[Wolf [:wolf]]

I've also attempted changing the mime type output by the install script..
as you can see from my previous comment.
header("Content-Type: application/x-java-archive");

Doesn't fix it either.

Comment 16

[cooperg]

How are you guys installing these themes manually? 
I'm on Linux (RHFC2) and cannot install them. The old method mentioned on
Texturizer.net does not work.  When I read about you guys 
saying it was a problem with the redirected URLs I downloaded the jar file 
and made a local HTML file that looked like this:

<a href="javascript:void(InstallTrigger.installChrome(InstallTrigger.SKIN,
'file:///home/userdir/Noia2_full.jar','Noia 2.0 (eXtreme)'))">click</a>

and it didn't work. This would seem to disprove the redirect hypothesis unless
I botched the HTML tag...

Comment 17

[James Ross]

(In reply to comment #16)
> <a href="javascript:void(InstallTrigger.installChrome(InstallTrigger.SKIN,
> 'file:///home/userdir/Noia2_full.jar','Noia 2.0 (eXtreme)'))">click</a>

Such a link works here... with both file: and http: URIs.

Comment 18

[Wolf [:wolf]]

OK, what I've done is change the URLs to not use the install.php script and just
link to the ftp server. 

This breaks the download counts though, so at this point, theme counts and most
popular themes is now nicely busted. :-(

What I'm not understanding is why this worked on an aviary branch build 0613,
and why theme manager is just deleting the entries rather than installing.

CC'ing Ben because theme manager is his. and Darin for possible clues about the
attached log. 

Comment 19

[Tim Meader]

That does seem to have fixed it for the time being.  Just wondering, with your
install.php, assuming that installTrigger can't handle the redirect for some
reason, have you tried simply having the php script open the file and write it
out instead? Something like:

$file = "http://whatever.host.com/file-to-download.xyz";
header("Content-Description: File Transfer");
header("Content-Type: application/octet-stream;");
header(--whatever else you need--)
@readfile($file);

Has worked in similar situations for me.

Comment 20

[Wolf [:wolf]]

I tried that as well, and it still broke.. which doesn't make sense. What's the
difference between that and just directly downloading?

Plus, that can't be ported to update itself, because of the way it uses the ftp
mirrors.

Comment 21

[James Ross]

Okay then, here's what my debug Mozilla had to say about this:

WARNING: getting z level of unregistered window, file
w:/mozilla/tree-debug/objdir/xpfe/appshell/src/../../../../../source-HEAD/mozilla/xpfe/appshell/src/nsWindowMediator.cpp,
line 636
WARNING: getting z level of unregistered window, file
w:/mozilla/tree-debug/objdir/xpfe/appshell/src/../../../../../source-HEAD/mozilla/xpfe/appshell/src/nsWindowMediator.cpp,
line 636
WARNING: nsTimeoutImpl::Release() proceeding without context., file
w:/mozilla/tree-debug/objdir/dom/src/base/../../../../../source-HEAD/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 5183
--WEBSHELL == 4
++WEBSHELL == 5
++DOMWINDOW == 6
--DOMWINDOW == 5
###!!! ASSERTION: XPIManager: output stream doesn't exist: 'mItem->mOutStream',
file
w:/mozilla/tree-debug/objdir/xpinstall/src/../../../../source-HEAD/mozilla/xpinstall/src/nsXPInstallManager.cpp,
line 892
WARNING: NS_ENSURE_TRUE(globalObject) failed, file
w:/mozilla/tree-debug/objdir/xpfe/appshell/src/../../../../../source-HEAD/mozilla/xpfe/appshell/src/nsWebShellWindow.cpp,
line 1080
WARNING: NS_ENSURE_TRUE(globalObject) failed, file
w:/mozilla/tree-debug/objdir/xpfe/appshell/src/../../../../../source-HEAD/mozilla/xpfe/appshell/src/nsWebShellWindow.cpp,
line 1080
WARNING: NS_ENSURE_TRUE(globalObject) failed, file
w:/mozilla/tree-debug/objdir/xpfe/appshell/src/../../../../../source-HEAD/mozilla/xpfe/appshell/src/nsWebShellWindow.cpp,
line 1080
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(EnsureScriptEnvironment())) failed, file
w:/mozilla/tree-debug/objdir/docshell/base/../../../../source-HEAD/mozilla/docshell/base/nsWebShell.cpp,
line 290
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(EnsureScriptEnvironment())) failed, file
w:/mozilla/tree-debug/objdir/docshell/base/../../../../source-HEAD/mozilla/docshell/base/nsWebShell.cpp,
line 290

I'm guessing the key one is this one:
    XPIManager: output stream doesn't exist: 'mItem->mOutStream'

We need an XPInstall guy or gal down here, I think.

Comment 22

[James Ross]

That was what happens when installing a theme via the redirect on UMO, for
reference.

Comment 23

[Tim Meader]

I may have thought of something. There are VERY OFTEN issues when trying to
download a file (even if you specify the filename in a Content header) that is
passed to you via a php (or .pl, whatever type of server side you are using)
script... IF the script itself ends in ".php". What happens is that the filename
that is passed on the client ends up being the name of the script itself, as if
the client stripped off the query string and uses the first filename it finds as
the name. This is a big issue on both IE and all the Mozilla platforms. It could
be solved, if you weren't using a scripting language like php, by removing the
extension from the server side executable. Unfortunately this isn't really an
option with php or most scripting languages, like perl or python, where they
rely on the extension for the interpreter. WHat I mentioned earlier, about using
mod_rewrite, was the way I eventually got around this issue. It allows you to,
in the URL, not use anything with an extension. Example line from my httpd.conf
file:

RewriteRule ^/tempdown/([a-zA-Z_\.0-9\-]+)/([a-zA-Z0-9]+)/(.*)
/wd/tempdownload.pl?file=/tempfiles/$1/$2/$3 [L]

Prior to this, every file I tried to download would be called "tempdownload.pl". 

I'm likely totally wrong about this, and admittedly I didn't explain this too
well, but Wolf, if you are interested, I would be willing to go more into it for
you.

Comment 24

[Darin Fisher]

From the log file it appears that the nsIStreamListener's OnStartRequest is
returning NS_ERROR_FAILURE (once the redirected URL is loaded).  I figure this
is probably the nsXPInstallManager::OnStartRequest code, but I haven't debugged
yet to verify that.

cc'ing dveditz

Comment 25

[Grey Nicholson (they/them)]

Interjection from a gormless end-user: both XPIs served from
http://www.v2studio.com/k/ show up as "serve.asp" in the Software Installation
dialogue; they both install successfully (although umo's setup's probably
completely different)

Comment 26

[Tim Meader]

GKN, yeah, that's the issue I'm talking about. I'm guessing that the XPI guys
have it now, so it should get taken care of. But regardless, the "server side
script with an extention replaces actual filename" bug sure is an infuriating
one sometimes... on IE and Mozilla :(

Comment 27

[James Ross]

(In reply to comment #26)
> GKN, yeah, that's the issue I'm talking about. I'm guessing that the XPI guys
> have it now, so it should get taken care of. But regardless, the "server side
> script with an extention replaces actual filename" bug sure is an infuriating
> one sometimes... on IE and Mozilla :(

You can use Content-Disposition to deal with this, though this is drifting way
off-topic. :)

Comment 28

[Tim Meader]

silver, agreed, last post about this, but that's just the thing...
Content-Disposition does NOT always fix this behavior. In some case, like the
one I posted, mod_rewrite was the only solution for what we were trying to do.  :(

Now here's hoping the XPI guys figure this out :)

Comment 29

[Michael Lefevre]

*** Bug 246885 has been marked as a duplicate of this bug. ***

Comment 30

[Michael Lefevre]

*** Bug 246954 has been marked as a duplicate of this bug. ***

Comment 31

[Robert Pendell]

The Theme InstallTrigger does work.  I guess to an extent.  It detects based on
either javascript command or mimetype (server supplied).

Example:
I upload test.xpi to my own server.  At the moment it is not configured with any
additional mimetypes.  Therefore Firefox will not know it is an extension.  It
will download it as any other file because the server passed the wrong mimetype
to Firefox.  No javascript was used.  If you setup the server with the proper
mimetype it works fine or if you use javascript to initiate the install it will
work.

The same applies to themes even though they are jar files instead.

In a previous post (I think the 6/11 build announcement) and prior ones they had
test examples.  None of them worked here but they worked on the install page
given.  Reason was is that javascript doesn't work on the forum (it won't come
up right) so they were posted as normal links.  The install page has them as
javascript links.  The javascript is the trigger and it works for the page. 
Here it won't work because the only other thing for Firefox to check is the
mimetype and that isn't getting passed from the server.

I verified with Firefox build 6/13/04.  I know I am a few builds behind so I
will _reverify_ with the 6/16 build when released.

The following extensions and themes are installed.  All via InstallTrigger.

Extensions:
Tabbrowser Extensions 1.10.200461401
All-in-one Gestures 0.11.1
DownloadWith 0.0.7 (after repackage)
RSS Reader 0.7
CuteMenus 0.3
Download Manager Tweak 0.4.3
Popup ALT Attribute 1.3.2004031001
Compact Menus 1.6.6

Themes:
Noia 2.0 (Extreme) 2.63
Noia 2.0 (Lite) 2.63
Smoke 1.5

And yes.  The qute theme in the link did install.

Comment 32

[George Deka]

Linux fx 0.9
I am witnessing the same behaviour as comment 16, where i cannot install themes 
using the texturiser method or even a custom page.
Is this the same issue, or possibley another issue that is linux only.

Comment 33

[cooperg]

To update comment 16, I'm on linux (RHFC2) as well, but I was able to 
finally install themes after deleting my profile and installing the 
theme without any old settings and before installing any extensions. 

Comment 34

[Michael Lefevre]

Given that the website now has a workaround, should this now be a browser
(networking?) bug?

Comment 35

[Wolf [:wolf]]

Yeah, this actually is a browser bug, though I'd like to get the attention of
Firefox people with it.. and get it fixed for 1.0. :-/ So i'm not sure if I
should move it to Browser where it might fall into the abyss or firefox. heh.

Comment 36

[Daniel Veditz [:dveditz]]

Move it to browser where it belongs (either necko or xpinstall, whichever seems
closer to the real issue) and add the blocking-1.0? nomination.

Comment 37

[Wolf [:wolf]]

Bouncing it over to Browser --> XPInstall based on Comment 24.

Comment 38

[alanjstr]

This is broken on UMO, too.

javascript:void(InstallTrigger.install({'BuscaP%C3%A9 Prices
Comparison1.0':'http://do-not-add.mozilla.org/developers/approvalfile.php/buscap%C3%A3%C2%A9-1.0-fx.xpi'}))

Comment 39

[d]

Any update on this bug yet?
Does the whole XPI/theme install need to be overhauled?