1016033 - Race in newSession > waitForWindow

Status: RESOLVED FIXED

(Remote Protocol :: Marionette, defect)

Description

[Alexandre Poirot [:ochameau]]

The following code races when being used against Mulet.
I can't explain why it doesn't race on Firefox, but the code looks very likely to race:
http://mxr.mozilla.org/mozilla-central/source/testing/marionette/marionette-server.js#506
  let checkTimer = Cc["@mozilla.org/timer;1"].createInstance(Ci.nsITimer);
  let win = this.getCurrentWindow();
  if (!win ||
      (appName == "Firefox" && !win.gBrowser) ||
      (appName == "Fennec" && !win.BrowserApp)) {
    checkTimer.initWithCallback(waitForWindow.bind(this), 100,
                                Ci.nsITimer.TYPE_ONE_SHOT);
  }
  else {
    this.startBrowser(win, true);
  }

The issue is that we are just waiting to gBrowser to "appear" on window object,
but it doesn't mean that gBrowser is ready to be used. And we are using various method of gBrowser like addTab in startBrowser->startSession. On Mulet, these calls ends up throwing or misbehave. Ideally we would wait for load event before using gBrowser.

Comment 1

[Alexandre Poirot [:ochameau]]

Attachment: patch

https://tbpl.mozilla.org/?tree=Try&rev=036f06b17e4d

Comment 2

[Jonathan Griffin (:jgriffin)]

Comment on attachment 8428824 [details] [diff] [review]
patch

Review of attachment 8428824 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for the patch!

Comment 3

[Alexandre Poirot [:ochameau]]

I think the few failing test on try are all intermittent:
  https://tbpl.mozilla.org/?tree=Try&rev=036f06b17e4d
And the G-oop looks like a failure due to the changeset I'm based on. I got it failing on few try run with different patches.

Comment 4

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/b2g-inbound/rev/1de73fe72d40

Comment 5

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/1de73fe72d40