298222 - Mozilla freezes when pref xpinstall.dialog.confirm points to a chrome URL that cannot be found

Status: RESOLVED DUPLICATE of bug 52967

(SeaMonkey :: Installer, defect)

Description

[Raj Bhaskar]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050619 MultiZilla/1.8.0.1n
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050619

If you set the pref "xpinstall.dialog.confirm" to a chrome:// URL that does not
exist (eg to an extension that is not currently installed), then the first time
that you try to install an extension, an error dialog appears and Mozilla
freezes and has to be killed through task manager.

Reproducible: Always

Steps to Reproduce:
1. Ensure that MultiZilla is NOT installed
2. In about:config, change "xpinstall.dialog.confirm" to
chrome://multiviews/content/xpinstall/xpinstallConfirm.xul
3. Try to install an extension (either through clicking a link or by dragging an
xpi file to the browser window)

Actual Results:  
Seamonkey freezes after displaying a dialog box saying that it can't find a file
(I'll get the actual text after entering this bug report)

Expected Results:  
Mozilla should display the error, but should not hang.  Ideally, the
xpinstall.dialog.confirm should be reset to its default value and the user
should be told to try again.

Comment 1

[Raj Bhaskar]

The error in the dialog box is: "The file
/content/xpinstall/xpinstallConfirm.xul cannot be found.  Please check the
location and try again."

You can dismiss the dialog, but after that, the entire Seamonkey UI becomes
unresponsive and you have to kill it through task manager.

Note: despite what my user agent says, I did /not/ have MultiZilla installed
when I was testing this bug.

Comment 2

[Leland M. George]

(In reply to comment #1)
> <snip/>
> Note: despite what my user agent says, I did /not/ have MultiZilla installed
> when I was testing this bug.

Raj,

You do mean not installed, as opposed to disabled?

There was a Mozilla bug a few months back that may be relevant.  HJ helped with
a workaround and possibly a patch,  Anyone got a clearer memory of this than I do?

Comment 3

[Raj Bhaskar]

> You do mean not installed, as opposed to disabled?

Yes, I mean not installed.  Sorry, I should have made this clearer.

Comment 4

[Leland M. George]

(In reply to comment #2)
> <snip/>
> There was a Mozilla bug a few months back that may be relevant.  HJ helped with
> a workaround and possibly a patch[.]
> <snip/>

Was referring to Bug #272764 (resolved fixed).  HJ's contributions start at Bug
#272764 Comment #9.  Possible connection to this bug is suggested at Bug #272764
Comment #34.  Maybe the fix broke something?

Comment 5

[OstGote!]

Related to Bug 52967? See also similiar bug 298222.

Comment 6

[Boris Zbarsky [:bzbarsky]]

*** This bug has been marked as a duplicate of 52967 ***