Closed
Bug 77627
Opened 23 years ago
Closed 23 years ago
Can't install xpi
Categories
(SeaMonkey :: Installer, defect)
Tracking
(Not tracked)
VERIFIED
WORKSFORME
mozilla0.9.4
People
(Reporter: public, Assigned: slogan)
References
()
Details
Attachments
(1 file)
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•23 years ago
|
||
could you post the sample .xpi somewhere?
Reporter | ||
Comment 2•23 years ago
|
||
Comment 4•23 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)
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
over to don due to problem with the download dialog. Don, I thought this was fixed?
Assignee: ssu → dbragg
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*.
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.
Assignee | ||
Comment 10•23 years ago
|
||
don, please have a look see.
Comment 12•23 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•23 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•23 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•23 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•23 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•23 years ago
|
||
Works when triggered, fails when launched directly. Will real users see this failure?
Comment 18•23 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•23 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•23 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+.
Comment 23•23 years ago
|
||
This one seems to work these days, I tried clicking on ftp, http and local file URLs.
Comment 24•23 years ago
|
||
WORKSFORME
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Updated•20 years ago
|
Product: Browser → Seamonkey
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.
Description
•