Closed Bug 1159358 Opened 9 years ago Closed 6 years ago

Make ContentSender aware of remotenes changes

Categories

(Remote Protocol :: Marionette, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1311041

People

(Reporter: ato, Unassigned)

Details

(Keywords: pi-marionette-server)

We should consider making the ContentSender aware of remoteness changes.

When get() is called today, its implementation in content space is split in two parts: A routine that receives the command call, called get, and a routine that waits for document.readyState to be "complete", called pollForReadyState.

Whenever a navigating causes the content frame to disappear, this is known as a remoteness change, and the new (remote) content frame needs to be initialised with a new listener.

We handle this by having chrome detect that a new registered content frame is actually a remoteness change in the Marionette:listenersAttached event that gets sent when a new listener registers.  This then sends newSession and an arbitrary number of “pending commands” which get previously populated with a call to pollForReady state, which by this point document.readyState == "complete", which then sends back Marionette:ok, which resolves the promise in get.

The code looks like this:

      let get = this.listener.get({url: url, pageTimeout: this.pageTimeout});
      let id = this.listener.curId;

      // If a remoteness update interrupts our page load, this will never return
      // We need to re-issue this request to correctly poll for readyState and
      // send errors.
      this.curBrowser.pendingCommands.push(() => {
        cmd.parameters.command_id = id;
        this.mm.broadcastAsyncMessage(
            "Marionette:pollForReadyState" + this.curBrowser.curFrameId,
            cmd.parameters);
      });

      yield get;

As you can see from this we tap into the ContentSender's internals and retrieve the current UUID for the current call.  It would be much better if this complexity was hidden away and if ContentSender could handle, or be aware so to speak, of remoteness changes.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.