Closed
Bug 27254
Opened 25 years ago
Closed 25 years ago
XPInstall blocked - can't get rid of confirmation dlg
Categories
(Core Graveyard :: Installer: XPInstall Engine, defect, P1)
Core Graveyard
Installer: XPInstall Engine
Tracking
(Not tracked)
VERIFIED
FIXED
M1
People
(Reporter: jimmykenlee, Assigned: cathleennscp)
Details
(Whiteboard: cathleen will check in later tonight.)
Attachments
(1 file)
|
1.56 KB,
patch
|
Details | Diff | Splinter Review |
Build: 2000-02-10-09-M14(WIN), 2000-02-10-08-M14(MAC), 2000-02-10-08-M14(LINUX)
1. From http://jimbob/trigger2.html, trigger any xpi file
RESULT:
XPInstall confirmation dialog appears. No module name and location names
appear. Clicking OK or Cancel buttons do nothing.
EXPECTED RESULT:
Module name and Location names appear. Clicking OK and Cancel buttons do
something.
none of the regression fixes went in this afternoon fixed this MAJOR regression.
XPInstall does not work at all!
Trying to look for help....
Keywords: beta1
Priority: P3 → P1
triggering ANY xpinstall is blocked.
Confirmation dialog comes up, but missing module name and location name, and YOU
CAN'T GET RID OF IT! (clicking OK or Cancel does nothing)
Summary: Triggering xpis results in blank confirm dialog and no installation → XPInstall blocked - can't get rid of confirmation dlg
Comment 4•25 years ago
|
||
I have nothing better to do. snagging from cathleen.
Assignee: cathleen → dougt
Comment 6•25 years ago
|
||
cc danm
Comment 7•25 years ago
|
||
This looks like a chrome bug. We create a window from C. The window.open url
parameter is:
chrome://xpinstall/content/institems.xul
The dialog is pretty vanilla. When the dialog accually gets opened, I see this
on the console:
JavaScript Error: syntax error
URL: http://jimbob/institems.js, line 1
It looks like it is using the current page that I am on as some sort of base
references.
The code that opens this window is here:
http://lxr.mozilla.org/seamonkey/source/xpinstall/src/nsXPInstallManager.cpp#176
ccing hyatt, and pinkerton. You guys know anything about this?
Target Milestone: M14 → M1
Comment 8•25 years ago
|
||
I belive that relative script tags in xul are broken. I am trying to verify
this.
Comment 9•25 years ago
|
||
work around found. going to use absolute chrome url;s
cathleen. could you check this in?
Assignee: dougt → cathleen
Whiteboard: cathleen will check in later tonight.
Comment 10•25 years ago
|
||
Comment 11•25 years ago
|
||
I wrote up another bug which address the real problem:
http://bugzilla.mozilla.org/show_bug.cgi?id=27355
| Assignee | ||
Comment 12•25 years ago
|
||
still waiting for the tree to open up...
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
| Assignee | ||
Comment 13•25 years ago
|
||
fix checked in for dougt.
| Reporter | ||
Comment 14•25 years ago
|
||
Build: 2000-02-11-09-M14(WIN), 2000-02-11-12-M14(MAC), 2000-02-11-11-M14(LINUX)
Back to normal. We can trigger xpis again.
Status: RESOLVED → VERIFIED
Updated•10 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•