User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5a) Gecko/20030528 Camino/0.7+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5a) Gecko/20030709 The IM button in the addressbook behaves very broken if XUL error pages are enabled. The current addressbook window is Reproducible: Always Steps to Reproduce: 1. Enable XUL error pages (browser.xul.error_pages.enabled = true) 2. Open AddressBook 3. Click on IM button in main toolbar Actual Results: The entire Address Book window became the Protocol Not Known error page. Only the title bar remained. All Addressbook toolbars disappeared. There was no way to return to the addressbook window. Closing Adressbook window and opening a new Addressbook was the only way. Expected Results: Should not show error page that wipes out an entire module window. Correct behavior up for debate, but it should be non-destructive like popping up an error box or showing the XUL error page in one of the addressbook frames (lower right one perhaps). If XUL error pages are NOT enabled, an error sheet pops down saying "AIM is not a registered protocol". Click OK and addressbook behaves normally. This is filed from an OS X 10.2.6 machine with latest nightly. Error also occurs on WinXP with Moz 1.3.1. There is no instant messenger of any kind installed on any of these computers, so AIM would never be a registered protocol.

Description got cut off. It should read: The IM button in the addressbook behaves very broken if XUL error pages are enabled. The current addressbook window becomes useless. Update: The window becomes unstable as well. Clicking around on the menubar quickly leads to a Mozilla crash. Talback ID: TB21756236H

Upping severity since this is a crasher. Should have been this from the beginning I think. As this is getting no attention from the addressbook component, who would be better suited for confirming and assigning?

Reporter: Do you still see this with a current trunk build ?

Testing with nightly trunk Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050423 The error page no longer shows up inside the addressbook as described in comment #0. Mozilla now asks about launching an external application: An external application must be launched to handle aim: links aim:goim Application: <Unknown> If you were not expecting this...blah blah. [Cancel] [Launch App] Pressing either Cancel OR Launch Application crashes mozilla-bin. After a long wait (longer than normal), Talkback appears. This new behavior occurs with browser.xul.error_pages.enabled set to either TRUE or FALSE (or non-existent as was the case with a new profile). The original description of this bug is now WFM, but I couldn't not find any bug related to the crashing...

Confirming, on my current trunk linux build the address book window gets replaced entirely by an XUL error page, and you can't even go back :-(

This patch tells the docshell not to use xul error pages (hence fixing the bug), and also changes the url loading to use web navigation direct rather than go through the nsIMessenger interface (I don't see any reason to do that here). If this all goes well, then I'd like to get this patch into the branch for 1.0b

Thunderbird doesn't actually have this problem at the moment as it doesn't have the IM button, however, in the hope that one day it may be put back, this patch will keep the code in sync. I'm not intending on putting this Thunderbird version on the 1.8 branch.

Comment on attachment 196931 [details] [diff] [review] SeaMonkey patch >+ window.QueryInterface(Components.interfaces.nsIInterfaceRequestor) >+ .getInterface(Components.interfaces.nsIWebNavigation) >+ .loadURI(url, null, null, null, null); The second parameter to loadURI is an integer, so you shouldn't pass null, you should pass in one of the web navigation load flags (either NONE or LINK). Or using window.location = url; works ;-) sr=me with this nit fixed.

Comment on attachment 196931 [details] [diff] [review] SeaMonkey patch Cancelling review request as I'm updating the patch.

Updated the SeaMonkey patch to address Neil's review comments. Carrying forward Neil's sr.

Comment on attachment 198249 [details] [diff] [review] SeaMonkey patch v2 (checked in to trunk and 1.8 branch) Requesting approval for checkin on branch for the SeaMonkey only patch. Low risk as it only affects involking Instant Messenging. I'm not going to request approval for the Thunderbird patch on this as Thunderbird doesn't appear to exhibit the problem, however if David or Scott wish to have it, then please request/set approval on that patch.

Comment on attachment 198249 [details] [diff] [review] SeaMonkey patch v2 (checked in to trunk and 1.8 branch) I just checked this into the trunk (branch waiting approval). /cvsroot/mozilla/mailnews/addrbook/resources/content/addressbook.js,v <-- addressbook.js new revision: 1.118; previous revision: 1.117

Comment on attachment 198249 [details] [diff] [review] SeaMonkey patch v2 (checked in to trunk and 1.8 branch) I just checked this patch into the branch. /cvsroot/mozilla/mailnews/addrbook/resources/content/addressbook.js,v <-- addressbook.js new revision: 1.117.2.1; previous revision: 1.117

Comment on attachment 196933 [details] [diff] [review] Thunderbird sync patch (checked in to trunk only) /cvsroot/mozilla/mail/components/addrbook/content/addressbook.js,v <-- addressbook.js new revision: 1.23; previous revision: 1.22

Although I did a sync patch for thunderbird, I'm leaving this in Suite as that where the main bug actually was. Both patches now in trunk & SeaMonkey patch in branch (thunderbird patch not required for branch) -> FIXED.

Verified FIXED using SeaMonkey 1.1a;Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051023 Mozilla/1.0 and Thunderbird version 1.6a1 (20051022)