User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199) Gecko/20060302 Debian/1.5.dfsg+188.8.131.52-2bpo1 Firefox/184.108.40.206 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11) Gecko/20060302 Debian/1.5.dfsg+18.104.22.168-2bpo1 Firefox/22.214.171.124 When a window dialog is opened from overlay, and that dialog tries to open a new tab with openUILinkIn, an exception is raised : 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowInternal.focus]" this is in chrome://browser/content/utilityOverlay.js (l474) w.content.focus() Reproducible: Always Steps to Reproduce: 1.open the file attached from an overlay with : window.open('chrome://yoono/content/popup.xul', 'popup', 'chrome,modal') 2. click on ok 3. Actual Results: tab opens in browser, but dialog doesn't close Expected Results: dialog should close. The dialog doesn't close due to an exception raised bug on windows, but not on debian (with .deb)
So the dialog is modal, which is why the content window can't be focused. I would say it's your fault and you should change your code to call openUILinkIn after the modal dialog is closed.
This bug was reported using a version of Firefox that security and stability updates are no longer provided for. All users are strongly encouraged to upgrade to Firefox 3 by selecting 'Check for Updates' in the Help menu or by going to http://www.mozilla.com/en-US/firefox/firefox.html If you can no longer reproduce this bug using the latest Firefox 3.0.x version, please change the status of this bug to 'RESOLVED' 'WORKSFORME'. If you can still reproduce this bug, please provide additional details to help resolve this issue.
No reply, INCOMPLETE. Please reply if you can still reproduce this bug with Firefox 3.5.3 or later in a new profile with the latest plugins (flash, quicktime, java, etc.).
Reading the initial comment and the answer from Nickolay I tend to mark this bug as invalid. You should check the return code of the dialog in the code which calls the dialog and use the openUILinkIn call there depending on the return value.
Actually, re-reading this bug, I think that the issue described in summary is indeed invalid, while the issue described in comment 0 (openUILinkIn not working) might be valid, but in either case it probably won't see any action without someone interested in patching it. So unless someone wants to argue this resolution, let it be invalid..
Neil, could you please quickly cross-check if this bug is invalid for sure or not?