3dom and iframes #1025

judax · 2020-02-13T22:43:43Z

Use case: A page contains a model-viewer instance but the functionality to control
that instance through 3dom scripts is emedded in an iframe.

ThreeDOMExecutionContext supports different modes: Standalone, ExternalWorker, ExternalPort.
One MessageChannel in ThreeDOMExecutionContext.
Worker can be null in ThreeDOMExecutionContext.
port2 can be exposed in ThreeDOMExecutionContext.
The scene-graph feature exposes new method: setThreeDOMExecutionContext.
New demo to show the iframe functionality.

googlebot · 2020-02-13T22:43:45Z

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

cdata · 2020-02-14T18:35:54Z

@judax very interesting idea. I wonder: could we spare most of the modifications required here if we abstracted at a lower level?

For example, we could allow specializations of the ThreeDOMExecutionContext like this:

class ThreeDOMExecutionContext extends EventTarget {
  // ...

  // Creates the isolated context where scripts run, and returns a reference to an object
  // with a Worker-like interface to communicate that context and control its lifecycle
  // NOTE: url may or may not be used depending on the implementation of this
  // method; there are good reasons for both approaches.
  protected createIsolatedContext(url: string): Worker {
    // Default implementation:
    return new Worker(url);
  }
}

With the above implementation, we could write a specialization for the host frame and a counterpart class for the child <iframe>:

/* === In the host frame context  === */

/**
 * A specialization of ThreeDOMExecutionContext that controls a Worker in a
 * remote <iframe>
 */
class HostThreeDOMExecutionContext extends ThreeDOMExecutionContext {
  // Override:
  protected createIsolatedContext(url: string): Worker {
    return new WorkerProxyInterfaceToIframe(url);
  }
}


/**
 * A class that looks like a Worker but actually controls execution in a remote
 * <iframe> context
 */
class WorkerProxyInterfaceToIframe implements Worker {
  protected iframe: HTMLIframeElement;

  constructor(url: string) {
    // Negotiate connection w/ iframe, pass in a dedicated MessagePort
    // Probably best to pass url into the iframe once communication is
    // established, rather than regenerate it inside the iframe
  }

  // Rest of Worker implementation goes here
  // @see https://github.com/microsoft/TypeScript/blob/master/lib/lib.dom.d.ts#L18821-L18830
}



/* === In the <iframe> context  === */

/**
 * Establishes connections with a host frame, creates Worker instances and
 * forwards messages to those workers
 */
class RemoteAgent {
  constructor() {
    self.addEventListener('message', (event) => {
      if (event.origin !== TRUSTED_GOOGLE_ORIGIN) {
        // Summarily ignored
        return;
      }
      // Establish connection with host context:
      this.negotiateConnection(event.ports[0]);
    });
  }

  protected onHostMessage(event: MessageEvent) {
    // Handle host commands to create workers on behalf of the
    // HostThreeDOMExecutionContext
    // Also forward messages from host to the workers
  }

  protected onWorkerMessage(event: MessageEvent) {
    // Forward message from the worker to the host context
  }
}

self.remoteAgent = new RemoteAgent();

In the example above, the WorkerProxyInterfaceToIframe class would be in an intermediary position between the ThreeDOMExecutionContext and the <iframe>. All messages passed from 3DOM intended for the Worker would be proxied by that class. The WorkerProxyInterfaceToIframe would be responsible for managing the relationship with the <iframe> and negotiating the connection to some special code (RemoteAgent in the example) in the <iframe>'s main thread.

The advantage of this approach is that 3DOM can generally remain agnostic to where the Worker runs the related script. It doesn't have to care about whether the Worker is spawned from the same execution context, or is perhaps running in Unity or some other remote context. Instead, it just cares that the thing it is communicating with has a Worker-like interface.

I'm interested to hear your thoughts on this.

Use case: A page contains a model-viewer instance but the functionality to control that instance through 3dom scripts is emedded in an iframe. * Modified ThreeDOMExecutionContext to create the worker using a factory method. * 2 new classes that inherit from ThreeDOMExecutionContext and override the worker creation method factory method. - HostThreeDOMExecutionContext: For the host page that includes the iframe. The returned worker is fake and just used to intercept the passing of the MessagePort. The port is transferred not to the worker in the host page but to a worker in the iframe page. This class handles all the handshake necessary with the iframe. - IFrameThreeDOMExecutionContext: For the iframe page. The returned worker is an actual worker but it waits to hand over the port until it is received from the host page. * The scene-graph feature exposes new method: setThreeDOMExecutionContext. * New demo to show the iframe functionality.

judax · 2020-02-20T06:00:38Z

Thanks for the feedback Chris. I took a new stab at the proposal following your advise.

Added an internal createWorker method in ThreeDOMExecutionContext to delegate the creation of the worker to a method that an inheriting class could override.
Created 2 new classes that inherit from ThreeDOMExecutionContext, one fort the host (main) page and one for the iframe page.
- HostThreeDOMExecutionContext: The worker is fake and captures the port when it is sent out to the worker. It handles all the handshake needed with the iframe page to hand over the captured port and inject the 3dom script passed from the iframe.
- IFrameThreeDOMExecutionContext: The worker is functional but it also captures the port passing and delays it until the port is received from the host page.

In this new approach I maintained the modification in the scene-graph mixin to set the execution context to model viewer in the host page. I was thinking that this could be done with yet another mixin, but some symbols from the current scene-graph mixin might need to be exported. This would let anyone to create new "flavors" of model-viewer as needed. Let me know what you think of this idea of using a mixin instead or if you have any other ideas.

lincolnfrog

Looks great!

lincolnfrog · 2020-02-20T20:10:35Z