...

• We don’t trust content authors (from a security attack vector standpoint)

• We should acknowledge that there are other places where XBlocks are rendered (not just MFEs)

• Dependencies of XBlocks should be explicitly defined (there should be no magic)

• Any solution should aim for unit page rendering performance to be comparable (or better!) to the current LMS or CMS implementations, particularly where a large number of XBlocks is concerned (think MIT courseware)

• Any solution must be backward compatible with existing, unmodified course content - in particular Problem, Video, and HTML (as in, this content can be rendered perfomantly without modification). In case of adding new, more performant content (via new XBlocks or a new version of the XBlock API), it should be possible for modified content to co-exist with unmodified content

• Keep both development and long-term maintenance simple

• Each solution should make a firm statement on whether the attack vector meant to be addressed by iframes will be handled, or not.

Approaches to discuss

Extracting XBlocks out of edx-platform

...

The summit was called to address issues with XBlock rendering, particularly focusing on performance problems encountered when rendering unit pages with many XBlocks. This has led to a poor user experience in Studio, prompting the need for a better solution.

“Single Iframe Solution” Proposal by Dave Ormsbee

...

(Axim)

• Instead of rendering each XBlock in its own iframe, use a single iframe for all XBlocks and manage their placement and interaction via post messages.Advantages: This would simplify the rendering process, improve in a Unit using the /xblock endpoint of the preview server.

  • Have that unit rendering include empty divs as placeholders.

  • Have the Authoring MFE overlay the per-Component toolbars on top of those placeholders.

  • The iframe contents use postMessage() to communicate the locations where those overlays are needed, in a way that is similar to what happens with iframe re-sizing on the Learning MFE.

• This is a more tactical proposal to move Studio to the new Unit page, and does not conflict with other, larger scale, long-term modernization efforts.

• Advantages:

  • Improves performance by reducing the number of iframes and significantly reducing the number of JS assets that need to be processed.

  • Does not require major rewrites of XBlock or runtime functionality–seems feasible to do for the Sumac timeframe.

  • In the longer term,

  and potentially streamline the user experience in Studio.Challenges: It requires significant adjustments to how XBlocks are currently handled, including managing dependencies and ensuring secure and efficient post-message communication

  • may provide us with better fidelity previews that are inline with the Unit itself (and give us a way to move off of needing a separate preview domain).

  • In the longer term, may give us an acceptable pattern for frontend plugins to decorate and interact with XBlock content (e.g. “submission history”, “staff debug”).

• Challenges:

  • Not a common pattern, which may lead to confusion.

  • Re-ordering components in a unit will likely require some special case handling (e.g. hiding the iframe and collapsing the component toolbars together), because we can’t reorder within the iframe document.

Proposal by Braden MacDonald

...