Closed Bug 88455 Opened 24 years ago Closed 24 years ago

Installing xpi results in browser crash/freeze

Categories

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

Product:
Core Graveyard
Component:
Installer: XPInstall Engine
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 78442
Milestone:
mozilla0.9.3

People

(Reporter: jimmykenlee, Assigned: slogan)

Details

(Keywords: crash, regression, Whiteboard: pdt+, investigating, trying to assess test application in real world)

Build: 2001-06-29-06-0.9.2(WIN), 2001-06-28-14-0.9.2(MAC), 2001-06-29-04-0.9.2(LINUX) 1. From http://jimbob/trigger3.html, click into Trigger URL field and add u_new65.xpi 2. Click Trigger button 3. Click OK button from Items to Install dialog RESULT: Install occurs. Download dialog stays open and does not dismiss. Install.log is not updated. Browser is frozen. EXPECTED RESULT: Install completes with no freeze. Install.log is updated. NOTE: There are many other test cases that leaves the browser in this "frozen" state. The test mentioned above is simply one of them.
Nominating! This is a regression. This directly impacts installing plugins, etc. This breaks website support. Some test cases freeze without the dialog being left in place.
Keywords: crash, nsbeta1, regression
Try pressing the stop button (that's in the release notes!) Also, in linux, installing new .xpi in folders not world writable (such as /usr/local/mozilla) need to be installed as root
Perhaps the Summary is not clear. The problem is not with installing Netscape/Mozilla. The problem is new with simply adding a file. There seems to be some problem during the Finalize state. I can see that my test adds a file. But the "freeze" occurs as the progress meter progresses for the finalize part. And it makes sense that this did not complete because my install.log does not reflect the expected detail or any detail.
Summary: Installing results in browser crash/freeze → Installing xpi results in browser crash/freeze
The summary was clear enough for me. I know what you meant. I had the same problem installing jre.xpi, but i noticed i was trying to install it as a normal user, and a normal user cant write to /usr (i never tested installing it as root anyway)
That's good info. I am installing on Win NT with admin privileges, so I don't see why I should fail. Plus I had been successful for several weeks with earlier builds.
Keywords: nsbeta1 → nsbeta1+, nsBranch
Target Milestone: --- → mozilla0.9.3
This seems an infrequent operation. Would millions of regular users do this?
I have no way to respond to that question. It's a crasher, it implies a core flaw in the product. One that may have manifestations that reach beyond the given test case.
It is somewhat difficult to measure the impact on this one. Not all xpis crash, but some certainly do. QA needs development to help identify the cause. This is a regression. Many users could be affected by this problem if a script writer inadvertantly deployed a xpi that happens to capture the cause of this crash.
pdt+ per selmer's comments.
Whiteboard: pdt+
Whiteboard: pdt+ → pdt+, investigating, trying to assess test application in real world
This is possibly a reproduceable case of topcrash bug 58573
*** This bug has been marked as a duplicate of 78442 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Build: 2001-07-17-05-0.9.2(WIN), 2001-07-17-03-0.9.2(MAC), 2001-07-17-03-0.9.2(LINUX) Works great now. Marking Verified. Will check trunk with Bug 78442.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.