295623 - window.openDialog locks up browser when chrome url given is broken

Status: RESOLVED DUPLICATE of bug 52967

(SeaMonkey :: UI Design, defect)

Description

[Todd A. Fisher]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050520 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050520 Firefox/1.0+

I am mirgating an application I built from firefox to xulrunner.  We open the 
chrome://browser/content/pref/pref.xul to set network properties.  Since this 
url no longer exists in xulrunner, executing the openDialog locks up the
application.  This is ok, as it's a bug in my application, but since it's
possible for me (or anyone else developing xul applications) to create a url
dynamically that could be mal-formed or incorrect, i think it might be a good
thing if openDialog had some extra checks to ensure that it doesn't lock up the
whole application.

Reproducible: Always

Steps to Reproduce:
1.  write some javascript in with chrome permissions, 
   window.openDialog( "chrome://browser/content/pref/pref.xul", "",
"centerscreen,chrome,modal=yes,dialog=yes");
2. put this in a xul window and execute it from xulrunner
3. put this in a xul window and execute it from firefox


Actual Results:  
In the first case under xulrunner the application locks up and with a debug
build an error message appears in the console.

In the second case under firefox the application displays the dialog and
everything works as expected.




Expected Results:  
Just to make sure it's clear, this bug is not about the fact that something
changed between firefox and xulrunner.  It is about the error handling of
window.openDialog.  It would be nice if openDialog would fail without locking up
the application.

Comment 1

[Mathew McBride]

this bug also occurs with JavaScript console in SeaMonkey. Any other XUL app
runs fine - using the browser in the same session to write this.

Someone with canconfirm please?

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050529

Comment 2

[OstGote!]

Is this a duplicate of Bug 52967? See also similiar bug 298222.

Comment 3

[Todd A. Fisher]

(In reply to comment #2)
> Is this a duplicate of Bug 52967? See also similiar bug 298222.

Yes, I believe, each of these bugs are duplicates.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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