60910 - Downloads two copies of XPI file being installed

Status: VERIFIED FIXED

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

Description

[Richard Biddle]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; m18) Gecko/20001113
BuildID:    2000111320

Adding a new theme (and maybe any new software install component) and the file
begins to download immediatly.  Next a dialog box appears asking if I want to
download it.  Then after saying yes, it begins to download the same file again
and continues the first one.
When the first one is completely downloaded it is ignored and the installer only
operates when the second copy has finished

Reproducible: Always
Steps to Reproduce:
Install a new skin, or maybe any component.
I used the View/Apply Theme.../Get new Theme option to get to:
http://x.themes.org/php/download.phtml?query=download&object=resources.chrome.966515700&server=themes.org


Actual Results:  The .xpi file was downloaded twice, but the first one ignored.

Expected Results:  Download only once.

I am using a program called Naviscope which shows excatly what files I am
receiving.  It is transparent to applications.

Comment 1

[Tony Jordan]

Reporter, are you still seeing this in current builds?  If so could you please
post a log from your monitoring software so we can see what is going on?

Changing component to installer.

Comment 2

[Richard Biddle]

The same thing happens in build 2000121304.  I will try and confirm that this
truely is a bug with mozilla.

Comment 3

[Keyser Sose]

WORKSFORME
Platform: PC
OS: Linux 2.2.16
Mozilla Build: 2000122808 M18 Trunk Build

Comment 4

[matt beauregard]

Tried this out, browser starts one download while asking whether I want to
install the theme, then attempts to start a second when I confirm.  The second
download stalls, and the download dialog box claims to be attempting to resolve
the hostname.  The machine's resolver is perfectly able to resolve the hostname,
as is the proxy cache's resolver, which is to be expected since the proxy cache
is busy downloading the xpi file.  Relevant cache logs:

978509388.479 143101 203.41.79.15 TCP_MISS/000 41239 GET
http://x.themes.org/downloads/chrome.975085632.xpi - DIRECT/x.themes.org -
978509406.178 122976 203.41.79.15 TCP_HIT/200 307340 GET
http://x.themes.org/downloads/chrome.975085632.xpi - NONE/- application/x-xpinstall

Comment 5

[Jure Repinc (JLP)]

Attachment: Browsing activity log

Comment 6

[Jure Repinc (JLP)]

Attachment: HTTP Request Log

Comment 7

[Jure Repinc (JLP)]

Attachment: HTTP Request Log

Comment 8

[Jure Repinc (JLP)]

Attachment: HTTP Request Log

Comment 9

[Jure Repinc (JLP)]

Attachment: HTTP Request Log

Comment 10

[Jure Repinc (JLP)]

Attachment: HTTP request log

Comment 11

[Keyser Sose]

Marking NEW a lot of people on #mozillazine saw this one after we worked on it.
Whether or not its Mozilla's problem is up for debate.

Comment 12

[Jure Repinc (JLP)]

Attachment: HTTP response log

Comment 13

[Jure Repinc (JLP)]

I attached Browsing activity log, HTTP Request log (sorry for multiple files) 
and HTTP response log from Naviscope 8.70.
Mozilla 2000123120 on Windows 2000.

It looks like Mozilla really downlods two files instead of just one.

Comment 14

[Richard Biddle]

Naviscope also shows that Mozilla appears to download shockwave files twice.
For example at: www.dvb.org
Shockwave splash file loads twice.
I do feel that the problem may caused by naviscope but I've never seen this
happen in IE.

Comment 15

[Sean Su]

adding dveditz and dbragg to the CC: list.

Comment 16

[Daniel Veditz [:dveditz]]

We'll want to fix this one. Adding dougt for Necko wisdom, we're probably doing 
something wrong, like our observer shouldn't be opening its own file we should 
somehow be able to get it from Necko.

Comment 17

[Daniel Veditz [:dveditz]]

Over to Don, who has other bugs dealing with the download stuff. The site 
referenced appears to simply serve a page with the correct MIME-type, which 
might have completely different behavior than a javascript call to 
InstallTrigger.install() where the XPInstall backend initiates the Necko 
request. In other words, test by clicking on .xpi links on sweetlou rather than 
by using QA's javascript-based test harness.

Comment 18

[Daniel Veditz [:dveditz]]

Correcting component

Comment 19

[dbragg]

p2 tasks

Comment 20

[dbragg]

Richard Biddle, Jure Repinc, Matt Beauregard,
I need some clarification here.  Either this has been fixed or I'm not
understanding the problem.  When I tried this with a build I made on 2/1/2001
I'm not seeing 2 download dialogs no matter how I try to get an .xpi file.  I do
see that the browser's progress bar (this is the progress bar at the bottom of
the browser window itself, NOT the one in the download dialog) is in the
undetermined stage with the "Items to Install" dialog is up but there is no
download going on at this stage.  As soon as I click "OK" the download dialog
comes up and the install completes correctly.

The clarification I need is whether you're actually seeing 2 download dialogs or
if the "first" download is somehow happening in the background without any UI?

Comment 21

[Richard Biddle]

Only one download dialog box ever appeared but Naviscope 

(naviscope.com) showed that two copies of the file were being 

downloaded.  One was ignored.

Comment 22

[dbragg]

I need some more information.  I've got Naviscope in my system now but it
doesn't recognize Netscape 6.  I've done some other investigation and can't see
any double downloading.

Richard, Does Naviscope give you any information on where this first download is
going?  Is it to your %TEMP% directory?  Is it to your profile somewhere?  I
need something I can see without Naviscope.  Is it possible this is Naviscope's
prefetch feature or something like that?

Comment 23

[Richard Biddle]

Attachment: Naviscope Browsing log

Comment 24

[Richard Biddle]

Attachment: Naviscope HTTP Requests

Comment 25

[Richard Biddle]

Attachment: Naviscope HTTP Responses

Comment 26

[Richard Biddle]

Attachment: Naviscope HTTP Responses

Comment 27

[dbragg]

Richard,
I thank you for posting more Naviscope reports but I'm afraid this doesn't
really help to distinguish whether this is a Naviscope related problem or a
Mozilla problem.  I'm very sorry if I haven't been clear on what I need.  I will
try to clarify...

I need the following:  When you get the Confirm dialog on Mozilla (the one that
says: "Items to Install" and lists the .xpi file) don't click OK.  While that
modal dialog is on the screen can you get a Naviscope report?  According to the
first report a download is happening at this time.  I see no evidence of this.

I have looked all over my system and I've traced through the code in the
debugger and can find no case where a double download is happening.  In the
initial bug report it was stated "Adding a new theme (and maybe any new software
install component) and the file begins to download immediatly."  I need to know
if the real file completes a download or if this is based on a Naviscope report.

If you are getting an actual file downloaded, to what location is it being
downloaded?  Our code downloads .xpi files to the system temp directory only.

Comment 28

[Richard Biddle]

Hello, sorry I haven't replied sooner but I only yesterday got access to a
Windows PC.  I installed Mozilla 0.8, and Naviscope 8.70 (from naviscope.com
download page (it said it was 8.6 something but it installed 8.70)).
Disabled all Naviscope functions. (no precaching etc).  Enabled Traceroute
(Right click 'N'. Select Traceroute).  Set Mozilla HTTP proxy to 127.0.0.1 Port
81.  And set Naviscope proxy to your previous Mozilla HTTP proxy (if you had one).

This is the whole sequence:

From Menu: View, Apply Theme, Get New Themes.
Find desired theme,
Click Quick download/install.
Naviscope shows that the .xpi file begins downloading immediately.  (Shown in
Browsing log at time 17:12:07)
And the Items to Install dialog comes up.

I waited 20 seconds before clicking OK.
This then began downloading a second copy of the .xpi file.  (Shown in Browsing
log at time 17:12:26). And the dialog changed to a dialog showing downloading
progress bar.  This progress bar matched the progress of the second downloading
file.

The first file has completed downloading by this time and is ignored.
Second file continues and is then installed.

Does this help?

I'll try it again and see where the first file is put.

Comment 29

[Richard Biddle]

OK, I just tried it on a Linux box using tcpflow to see exactly what I'm
getting/sending.

Same bug!! (almost)  It begins downloading the first .xpi file immediately but
stops after receiving 66608 bytes.
Clicking OK begins the download of the second .xpi file and this time the whole
file is received.

Comment 30

[dbragg]

Ok, NOW I see what's going on.  The x.themes.org sight is using the mime-type
"triggering" mechanism instead of javascript triggering.  This is a known issue.

Reassigning to mscott per discussion with dougt.

mscott: to test this just click on an .xpi file in some test URL.  (but you'll
probably mark this as a duplicate ;-)

Comment 31

[Scott MacGregor]

I'm not sure I understand why this is assigned to me? What do you mean by mime
type triggering vs. js triggering?

the uriloader and exthandler don't do anything special with regards to
"triggering"........

Comment 32

[dbragg]

Actually Dougt told me to assign this to you, Scott.  He said this was a known
problem.  See, if the site uses a javascript trigger in their .html file
(InstallTrigger.install(xpifilename)) to download and run an .xpi file the
problem doesn't happen but if the user just clicks on an .xpi file, a little bit
of it starts to download immediately.  This is what the x.themes.org site is
really doing with their download button.

Now I don't know if this is really a bug or if a little bit of the file is being
downloaded on purpose for information reasons or whatever but xpinstall doesn't
actually start any explicit downloading until the Confirm dialog is dismissed.

Comment 33

[scottputterman]

moving to mozilla0.9.1

Comment 34

[scottputterman]

moving to 0.9.2

Comment 35

[scottputterman]

moving to 0.9.3

Comment 36

[scottputterman]

moving to 0.9.4

Comment 37

[scottputterman]

moving to 0.9.5

Comment 38

[Richard Biddle]

Well... This bug is no longer appearing in mozilla build 2001102808.
Someone please mark it as fixed.

Comment 39

[scottputterman]

moving to 0.9.9 but if it's believe to be fixed, please mark it as such.

Comment 40

[Scott MacGregor]

marking fixed per the reporters comments. 

Comment 41

[Daniel Veditz [:dveditz]]

I'm still seeing this.... :-(

Comment 42

[Daniel Veditz [:dveditz]]

taking...

Comment 43

[Richard Biddle]

What method are you using to detect it?

Comment 44

[Syd Logan]

--> dprice

Comment 45

[dprice (gone)]

Attachment: Patch to cancel the first request.

Comment 46

[dprice (gone)]

I tested by going to
http://ftp.mozilla.org/pub/mozilla/nightly/2002-02-12-10-trunk/windows-xpi/ and
downloading browser.xpi  I saw a download happening in the browser window.  When
I stopped that one, the download started in the confirm dialog.

Comment 47

[Syd Logan]

I can't speak for the solution, but I am wondering if we need to do a check to
make sure the request interface that Cancel() is being invoked off of is
actually non-NULL. Is it guaranteed this interface is passed in by the caller?

Comment 48

[Daniel Veditz [:dveditz]]

> if (!request) return NS_ERROR_NULL_POINTER;

is already in the code, scroll up :-)

Comment 49

[Daniel Veditz [:dveditz]]

Comment on attachment 69168 [details] [diff] [review]
Patch to cancel the first request.

could you move the cancel higher up? We want to Cancel the request regardless
of all the early returns, otherwise some potentially big file will still get
downloaded into your cache, wasting user bandwidth and flushing more useful
stuff from it.

I think you could do it any time after you get the URI from the channel.
Certainly you want to do it before StartSoftwareUpdate() because then it'll
still be downloading stuff the whole time the user is looking at the confirm
dialog.

Comment 50

[Daniel Veditz [:dveditz]]

Comment on attachment 69168 [details] [diff] [review]
Patch to cancel the first request.

>         if (uri) {    
>             char* spec;
>             uri->GetSpec(&spec);

Oh, as long as you're here... please make spec a nsXPIDLCString
rather than manually freeing. That way it doesn't get leaked if
for some reason you can't get the globalObjectOwner or globalObject,
and it'll be more robust in the face of future people adding
more early returns for whatever reason.

Comment 51

[Gagan]

Comment on attachment 69168 [details] [diff] [review]
Patch to cancel the first request.

r=gagan

Comment 52

[dprice (gone)]

Attachment: new patch

New patch cancels the request as soon as we get its uri and changes spec from a
char* to a nsXPIDLCString

Comment 53

[Daniel Veditz [:dveditz]]

Comment on attachment 69371 [details] [diff] [review]
new patch

sr=dveditz

Comment 54

[dprice (gone)]

checked in

Comment 55

[Jimmy Lee]

Reassigning QA Contact to me.  I have time to take this on.

Comment 56

[Jimmy Lee]

Build: 2002-03-19-10-trunk(WIN),2002-03-20-08-trunk(MAC),2002-03-20-08-trunk(LINUX)

Looks good to me.  I am not seeing multiple downloads.  Marking Verified.