When two Web Consoles are open on two tabs with the same URI and one is closed, the second one throws errors when closed. The proposed patch fixes this issue. I noticed this bug when fixing an issue that would cause the test "browser_webconsole_bug _597103_deactivateHUDForContext_unfocused_window.js" for bug 597103 to fail when the browser home page was set to an unreachable URL. This patch fixes the bug in that test, which allows it to serve as a test case for this issue as well.

Comment on attachment 484499 [details] [diff] [review] Proposed patch. The patch looks good to me. Thanks for the test fix!

Per a discussion with gavin in #devtools, this test failure is more mysterious than it seems. I can reliably reproduce the test failure by disabling my network connection. The issue is that the URL http://www.mozilla.org/projects/firefox/4.0b8pre/firstrun/ automatically loads in a new tab in the window that OpenBrowserWindow() opens, and the loading of *that* page is what triggers the tab2Loaded() event. If that page doesn't load, then the event never occurs. Changing OpenBrowserWindow() to window.openDialog() avoids the loading of that URL (because it bypasses the "defaultArgs" property of the nsIBrowserHandler), and this allows the test to succeed. The strange issues are as follows: (1) The newly-created tab created by the line "tab2 = win2.gBrowser.addTab()" cannot be made into the selected tab by the line "win2.gBrowser.selectedTab = tab2". The selected tab remains set to the URL http://www.mozilla.org/projects/firefox/4.0b8pre/firstrun/. (2) Until that Mozilla URI is successfully loaded, "tab2" never loads, and therefore the "tab2Loaded" event never fires. Based on this, I have a feeling this might be CSR related, but I'm not sure.

The problem can also be reproduced by changing "TEST_URI" in the window.openDialog() call to an invalid URI that never loads.

Wrapping the addTab() call in a setTimeout(function() { ... addTab() ... }, 0) wrapper fixes the issue.

What's the current status of this? (and is it just a test failure?)

Still applies. It's more or less just a test failure; as I recall I've never seen it outside of that environment.

mass change: filter on PRIORITYSETTING

removing blocking flag, since this is apparently a test-only problem.

This bug (and patch) is no longer valid. There have been numerous code changes which make this code obsolete.

marking invalid based on c#9.