Henrik Skupin [:whimboo][⌚️UTC+2] Assignee
	Description • 7 years ago

The problem here is part of the `new_session` command which endpoint in Marionette is `newSession`. In that method we have two promises for registering browsers, and waiting for listeners attached. The faulty one is the latter:

https://dxr.mozilla.org/mozilla-central/rev/211d4dd61025c0a40caea7a54c9066e051bdde8c/testing/marionette/driver.js#628-637

As you can see we handle the `Marionette:listenersAttached` message, but we actually do not care about from which browser it comes. This means if multiple tabs are open, and the selected one is not the first one, we resolve the promise already for the very first tab, but do not wait until the listeners for our wanted tab's browser have been attached. As such the next command which gets executed in content scope will fail because the end-point for the message doens't exist yet.

	Henrik Skupin [:whimboo][⌚️UTC+2] Assignee
	Comment 1 • 7 years ago

Actually it's not only the `newSession` command but every command which uses the `listeningPromise`. This includes switching tabs and frames.

	Henrik Skupin [:whimboo][⌚️UTC+2] Assignee
	Comment 3 • 7 years ago

I don't know how as best create a reliable testcase for this issue. Given that different builds are slower or faster it makes it hard. And we talk about some milliseconds here. So I triggered a try build, and if it is green we should get it in.

	Henrik Skupin [:whimboo][⌚️UTC+2] Assignee
	Comment 4 • 7 years ago

So the try build failed because with the current code in listener.js we only return a valid listener ID via the `Marionette:listenersAttached` message if a remoteness change has happened. This is pretty bad because we have lots of reloads of the listener nowadays which is not causing a remoteness change.

Given that I did all the frame script reload refactoring in bug 1332122 I'm tempted to include this small change into the patch set of the other bug instead. Even with the risk that we cannot uplift it to beta and/or 52esr.