1014080 - When dragging tab to existing window: "A coding exception was thrown in a Promise resolution callback. ... TypeError: msg.target.messageManager is undefined"

Status: RESOLVED DUPLICATE of bug 1013722

(Firefox :: New Tab Page, defect)

Description

[Daniel Holbert [:dholbert]]

STR:
 0. Start Firefox (nightly) from a terminal. Keep the terminal in view.

 1. Ctrl+N to open a new (second) Firefox window, with only one tab, at about:home (though location doesn't seem to matter).

 2. Drag that tab back to your original window.

ACTUAL RESULTS: This appears in your terminal:
{
*************************
A coding exception was thrown in a Promise resolution callback.

Full message: TypeError: msg.target.messageManager is undefined
See https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Promise.jsm/Promise
Full stack: this.ContentSearch._reply@resource://app/modules/ContentSearch.jsm:123:5
this.ContentSearch.onGetState@resource://app/modules/ContentSearch.jsm:74:5
this.ContentSearch.receiveMessage/<@resource://app/modules/ContentSearch.jsm:68:9
Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:863:11
this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:742:7

*************************
}


Additionally, after 5-10 seconds, this error appears in the Browser Console:
{
A promise chain failed to handle a rejection.

Date: Wed May 21 2014 09:47:11 GMT-0700 (PDT)
Full Message: TypeError: msg.target.messageManager is undefined
}
...linking to ContentSearch.jsm:123, which is this code:

>122   _reply: function (msg, type, data) {
>123     msg.target.messageManager.sendAsyncMessage(...this._msgArgs(type, data));
>124   },
http://mxr.mozilla.org/mozilla-central/source/browser/modules/ContentSearch.jsm?rev=345a99667b7c#123

Adding dependency on bug 962490, which added this _reply function. (Not sure this started with that bug's checkin, but just getting it hooked up for relatedness at least.)

Comment 1

[Daniel Holbert [:dholbert]]

Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0
32.0a1 (2014-05-21)

Comment 2

[Drew Willcoxon :adw]

Thanks for CC'ing me.  Bug 1013722 fixes this and is more or less a duplicate.

But the circumstances here are different, and at first I wasn't sure why this would be happening when it seems like about:newtab isn't involved at all.  When the tab is dragged and dropped, this ends up happening:

Preloader_newTab@resource:///modules/BrowserNewTabPreloader.jsm:81:13
addTab@chrome://browser/content/tabbrowser.xml:1610:15
_beginRemoveTab@chrome://browser/content/tabbrowser.xml:1928:49
swapBrowsersAndCloseOther@chrome://browser/content/tabbrowser.xml:2186:17
onxbldrop@chrome://browser/content/tabbrowser.xml:4427:11

tabbrowser.xml is preprocessed so the line number is off.  It's actually http://mxr.mozilla.org/mozilla-central/source/browser/base/content/tabbrowser.xml?rev=4dc06a48ed13#1624

So as part of the drag and drop process, tabbrowser ends up creating an about:newtab tab that's swapped out of the newtab preloader, triggering the mutation observer in page.js, which then calls gSearch.setUpInitialState, which sends a GetState message to ContentSearch.

I think what then happens is that the new about:newtab page is swapped for the dragged page in the other window; then the about:newtab that's now in the other window is closed, giving the illusion that the tab was moved.

So the about:newtab is gone before ContentSearch can reply to it.