[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWebProgress.addProgressListener]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://messenger/content/tabmail.xml :: openTab :: line 621" data: no] -- Exception object -- + toString (function) 3 lines + name (string) 'NS_ERROR_FAILURE' + message (string) 'Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWebProgress.addProgressListener]' + result (number) 2147500037 + filename (string) 'chrome://messenger/content/tabmail.xml' + lineNumber (number) 621 + columnNumber (number) 0 + data (object) null + stack (string) 'openTab@chrome://messenger/content/tabmail.xml:621:13 OpenMessageInNewTab@chrome://messenger/content/msgMail3PaneWindow.js:1155:3 oncommand@chrome://messenger/content/messenger.xul:1:1 ' + location (object) JS frame :: chrome://messenger/content/tabmail.xml :: openTab :: line 621 * -- Stack Trace -- openTab@chrome://messenger/content/tabmail.xml:621:13 OpenMessageInNewTab@chrome://messenger/content/msgMail3PaneWindow.js:1155:3 oncommand@chrome://messenger/content/messenger.xul:1:1 Looks like a regression from our WE stuff, bug 1455471.

Richard, do you see this in a Daily?

You can see this on automation as well, for example here: https://taskcluster-artifacts.net/ZwfrfnpuSLO8FQn3oa7Tww/0/public/logs/live_backing.log

Yes, I see this too. Interestingly the first time it shows no error but opens the tab in background. And from the second time it shows the error ...and opens the tab also in background.

I mentioned this in bug 1455471 comment 16. Now I understand what the cause is. A "new" tab of some times isn't new at all, it's the same tab reused for the new purpose. So adding the listener a second time raises an exception. I think we can safely catch the exception and move on.

Comment on attachment 8989098 [details] [diff] [review] 1472494-newtab-error-1.diff Review of attachment 8989098 [details] [diff] [review]: ----------------------------------------------------------------- Hmm, is there no better way to do this? Can't we track whether we've already attached a listener? For example, in MsgComposeCommands.js we have a dictionaryRemovalObserver with an 'isAdded' property. Could something similar be done here? I haven't looked at all. ::: mail/base/content/tabmail.xml @@ +619,5 @@ > // support, so let's assume one browser only for now. > + try { > + browser.webProgress.addProgressListener(this, Ci.nsIWebProgress.NOTIFY_ALL); > + } catch (ex) { > + if (ex.result != Components.results.NS_ERROR_FAILURE) { // Listener already added. This should be Cr., no? We've been replacing with Ci., Cu. and Cr. all over.

Better?

Comment on attachment 8989132 [details] [diff] [review] 1472494-newtab-error-2.diff (In reply to Geoff Lankow (:darktrojan) from comment #6) > Better? Well, you tell me. I think it's always better to consciously control than to deal with the fallout of random events.

Landing tonight after the next M-C merge. You know the game ;-)

Does with this patch the tab open again in front when opening it (see comment 3)? Or am I the only there this happens?

Pushed by mozilla@jorgk.com: https://hg.mozilla.org/comm-central/rev/7afe77cf1461 don't attach progress listener more than once. r=jorgk

Umm, "Open Message in New Tab" always seems to open in a non-active tab. Am I missing something or are you?

Tested now also on TB 52 as reference. Yes double click opens in front and through menu in background.

Beta (TB 62): https://hg.mozilla.org/releases/comm-beta/rev/c18560d6ce40