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)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: jimmykenlee, Assigned: cathleennscp)

Details

(Whiteboard: cathleen will check in later tonight.)

Attachments

(1 file)

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
Target Milestone: M14
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
unable to find any help... :-(
I have nothing better to do. snagging from cathleen.
Assignee: cathleen → dougt
Thanks Doug! :-)
cc danm
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
I belive that relative script tags in xul are broken. I am trying to verify this.
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.
I wrote up another bug which address the real problem: http://bugzilla.mozilla.org/show_bug.cgi?id=27355
still waiting for the tree to open up...
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
fix checked in for dougt.
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
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: