Status

SeaMonkey
Installer
VERIFIED WORKSFORME
17 years ago
4 years ago

People

(Reporter: Topics Man, Assigned: Syd Logan)

Tracking

Trunk
mozilla0.9.4
x86
Windows NT
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
Ive built 0.8.1 and tried to register a simple chrome XPI (barley.xpi, from one 
of the on-line intros) from a local copy using both the File/New and the URL 
bar. Mozilla did not complete its installation - the progress bar remained in 
the "ongoing" state and the cursor stayed in the hourglass state in the main 
browser window. Tried this several times from clean start, with same result.

Comment 1

17 years ago
could you post the sample .xpi somewhere?
(Reporter)

Comment 2

17 years ago
Created attachment 32295 [details]
As requested (from your doc "Creating New Packages for Mozilla" at http://www.mozilla.org/docs/xul/xulnotes/xulnote_packages.html)
can't really test this till bug 79617 is fixed....
Depends on: 79617

Comment 4

17 years ago
This Works For Me with Win98 build 2001062204

Probably related to the bug where XPIs without a MIME type couldn't install
which was fixed on the 15th. 

Reporter, Please try this again with the latest build (or 0.9.2 when it comes
out) and mark WORKSFORME if suitable.

(Also, with the latest XUL changes, I don't know whether the Barley example will
work perfectly. when I ran it it had no labels on the buttons)

Comment 5

17 years ago
changing component
reassigning
adding url
and confirming with build 2001062204 win32
I tested with the URL:

Steps to reproduce:
1.open the URL:
http://www.mozilla.org/docs/xul/xulnotes/xulnote_packages.html#create
2.scroll down to barley.xpi
3. click on it
4. click on OK

Expected result: barley.xpi gets installed

Current result: the Downloading... dialog freezes


Assignee: asa → ssu
Status: UNCONFIRMED → NEW
Component: Browser-General → Installer: XPI Packages
Ever confirmed: true
QA Contact: doronr → gbush
Summary: Cant load chromes → Can't install xpi

Comment 6

17 years ago
over to don due to problem with the download dialog.  Don, I thought this was 
fixed?
Assignee: ssu → dbragg

Comment 7

17 years ago
I don't believe this is a problem with the download dialog.  After a preliminary
check (I don't have a current debug build yet) it looks like something broke
underneath us.  *sigh*.

Comment 8

17 years ago
Reassigning to Syd.
Assignee: dbragg → syd

Comment 9

17 years ago
Ok, I made a debug build and it looks like weirdness in necko.  In
nsXPInstallManager.cpp in the DownloadNext function it looks like we're doing
the right things as far as new URI/URLs and channels.  But none of the callbacks
gets called.  No OnStartRequest, No OnDataAvailable, etc.

Now, if you start the download again (e.g. clicking on the barley.xpi mentioned
in the test case) without stopping the first, frozen one, then all the same code
in DownloadNext() gets called but the callbacks are now executed correctly. 
This is all related to the FIRST download you started because as soon as this
completes you get the Confirm dialog for the second download process.  From here
on, all downloads work correctly.  

So, it looks like there's some kind of deadlock or something going on in necko.

My $0.02.

Updated

17 years ago
Blocks: 84461
(Assignee)

Comment 10

17 years ago
don, please have a look see.
Assignee: syd → dbragg
Keywords: nsbeta1+
Target Milestone: --- → mozilla0.9.3
(Assignee)

Comment 11

17 years ago
reassigning to dougt
Assignee: dbragg → dougt

Comment 12

17 years ago
This isn't a necko problem.  It looks like events are not getting processed by 
the progress dialog.  If, for example, you cancel the dialog, XPInstall will get 
its first onStartRequest, followed by a cached onStopRequest.  

The thread that is calling AsyncOpen() needs to be processing event.  I don't 
think that is happening right now.

If this happens on the branch, this is a stop ship bug.  Grace  - can you see if 
you can reproduce this with the branch build.  Reassign back to don.

don, verify that PLEvents are being process by this thread.  Since it is a 
"dialog", maybe we are pushing an event queue can events in the elder queue are 
being ignored?
Assignee: dougt → dbragg

Comment 13

17 years ago
This isn't a necko problem.  It looks like events are not getting processed by 
the progress dialog.  If, for example, you cancel the dialog, XPInstall will get 
its first onStartRequest, followed by a cached onStopRequest.  

The thread that is calling AsyncOpen() needs to be processing event.  I don't 
think that is happening right now.

If this happens on the branch, this is a stop ship bug.  Grace  - can you see if 
you can reproduce this with the branch build.  Reassign back to don.

don, verify that PLEvents are being process by this thread.  Since it is a 
"dialog", maybe we are pushing an event queue can events in the elder queue 
are being ignored?

Comment 14

17 years ago
This looks like a flavor of 80171 but not exactly.  I've verified that if you
use the barley.xpi test by simply clicking on it you can easily reproduce the
hang.  But if you trigger it (i.e. paste the barley.xpi url into
http://jimbob/trigger3.html in the Trigger URL: edit box) it works just fine.

I've also traced this back to sometime between May 5, 2001 and June 1, 2001.  I
couldn't get any finer than that because those are the only builds of that
vintage on sweetlou.

Comment 15

17 years ago
I'm not sure if this is what you meant Doug, but I did the folowing:
1. Put a breakpoint on the call to async_open in nsXPInstallManager.cpp
2. Put a breakpoint at the start of OnStartRequest in nsXPInstallManager.cpp
3. Ran the test using the trigger (not the mime handler)
4. Checked the thread when the async_open call happened (thread 108)
5. Continued running and checked the thread when OnStartRequest callback was
called.  It was the same thread (108)
6. Allowed installation to complete successfully
7. Ran the test again (in the same mozilla session) but this time by putting the
url in the url bar rather than using the trigger
8. Install completed successfully
9. Closed that mozilla session and started a new one
10. Ran the test using the url bar and it never reaches the OnStartRequest.

Do you still think this is a problem with not having the same thread for
async_open and PL event processing?

Comment 16

17 years ago
I've traced it from PL_ProcessPendingEvents to the main nsAppShell::Run loop. 
It just sits in the do while loop.  It's almost as if the events have been lost
or something.  I know that's not it but that's kind of what it looks like.

Comment 17

17 years ago
Works when triggered, fails when launched directly.  Will real users see this
failure?

Comment 18

17 years ago
That totally depends on how .xpi files are served.  It forces a website to use a
trigger mechanism rather than just a link.  I know x.themes.org was just using a
link (at least a while ago).  I believe this could be a huge problem for plugin
creators.

By the way, Doug said he'd work on this if we get it PDT+'d.  I still think it's
either a necko problem or some problem relating to mime-type handling and necko.
 What do I need to do to get a PDT+ ?

Comment 19

17 years ago
Builds: 2001-07-10-05-0.9.2(WIN), 2001-07-10-03-0.9.2(MAC), 
2001-07-10-08-0.9.2(LINUX)

For all platforms on branch, I am still able to reproduce the problem clicking 
on barley.xpi.  I copied barley.xpi to my own server, http://jimbob/jars/, and I 
can still reproduce the problem.  What is unusual to me is that I can click on 
some of my own .xpi's, and I can install with no problem.

Interesting note is that when I saved the barley.xpi to my desktop, the Save 
File dialog stayed open similar to the XPInstall download dialog.  The progress 
meter also did not appear.  But the file did get saved to my desktop.

Comment 20

17 years ago
Per discussion with Dougt, he said he'd work on this bug if it got a PDT+.  I
really don't believe this is an xpinstall problem and needs to be addressed by a
Necko person.

Needs PDT+.
Don has moved to another group. Install bugs -> syd
Assignee: dbragg → syd

Comment 22

17 years ago
Missed 0.9.3.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
This one seems to work these days, I tried clicking on ftp, http and local file
URLs.
WORKSFORME
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 25

17 years ago
worksforme 2
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey

Updated

10 years ago
Component: Installer: XPI Packages → Installer
QA Contact: agracebush → general
You need to log in before you can comment on or make changes to this bug.