Edit Visually browser extension – iteration 2

[adamziel]

🚧 A more involved description TBD 🚧

Large changes:

• Snappy loading
• WordPress, PHP, and everything needed to run the editor is now shipped with the extension.
• There's no more iframe and a modal. Instead, there's a separate editor window. Manifest v3 makes the iframe non-feasible.
• An external domain with a loopback service worker is used to work around Manifest v3 limitation
• Extension service worker is involved, which breaks Firefox compat (not sure about Safari)

cc @dmsnell

[brandonpayton]

I made a note to poke at this tomorrow. I'd love to see more of what you've done here.

Manifest v3 makes the iframe non-feasible.
An external domain with a loopback service worker is used to work around Manifest v3 limitation

What is this limitation?

Extension service worker is involved, which breaks Firefox compat (not sure about Safari)

It is probably possible to use the older background page approach for a manifest v3 Firefox extension, once you are happy with the Chrome version.

Also, IIRC, the offscreen document being used here was created to fill a gap that was left when Chrome switched away from background pages, so I wonder whether the background page in Firefox could serve in the same way. (Or perhaps Firefox also has support for offscreen documents).

[adamziel]

What is this limitation?

@brandonpayton tl;dr, you either can't eval() and use inline <script> tags on content served from the extension, or, when using a "sandbox" page, you can't have a service worker.

A fuller answer is on these diagrams I drawn while exploring different avenues:

---

---

[adamziel]

This worked for me for eval and including custom scripts:

HTML:

<iframe src="chrome-extension://hjaafimkfjnfdabpmpcilmpiemgmjcgb/sandbox-page.html?abc" sandbox="allow-same-origin allow-scripts allow-popups allow-forms"></iframe>

Manifest.json:

  "sandbox": {
    "pages": [
      "sandboxed-page.html"
    ]
  },
  "web_accessible_resources": [
    {
      "resources": [ "sandboxed-page.html" ],
      "matches": [ "<all_urls>" ]
    }
  ],
  "content_security_policy": {
    "sandbox": "sandbox allow-scripts allow-forms allow-popups allow-modals; script-src 'self' 'unsafe-inline' 'unsafe-eval'; child-src 'self' https://playground.wordpress.net/; frame-src 'self' https://playground.wordpress.net/;"
  },

---

Another idea is to postMessage to an external iframe that runs the code and responds with the results. For that, this setup worked for me:

Manifest.json:

    "content_security_policy": {
        "extension_pages": "script-src 'self' 'wasm-unsafe-eval'; default-src 'self';child-src 'self' https://playground.wordpress.net/; frame-src 'self' https://playground.wordpress.net/;"
    },
    "web_accessible_resources": [
        {
            "resources": ["regular-extension-page.html"],
            "matches": ["<all_urls>"]
        }
    ],

regular-extension-page.html:

<iframe
    src="https://playground.wordpress.net/"
    sandbox="allow-same-origin allow-scripts allow-popups allow-forms"
></iframe>

[adamziel]

Here's a bunch of notes I took when exploring this

• Chrome extensions are extremely restricted in their ability to run JavaScript. Manifest V3 limits running inline scripts, eval(), iframes , and more.
• Goal: Iframe Gutenberg in Playground within GitHub. Preload it after the page load. Do not preload one wasm module per GitHub tab as that would get very slow very quickly. Instead, only run a single Playground site and point all the iframes there.
• Manifest V3 limitations
  • No inline <script> tags at all, not even this:

<script integrity_no="sha256-vv1iqjMZ5xNXCek5kMHs5l1Vmbsbmbn3V/dLMQlI/HQ=" 
        crossorigin="anonymous">

- Can't enable ^ in manifest.json, even with script-src 'sha256-vv1iqjMZ5xNXCek5kMHs5l1Vmbsbmbn3V/dLMQlI/HQ=' – the browser complains about unsecure CSP and refuses to load the extension.

• Challenges
  • Run a WordPress site.

    • Idea 1: Loading Playground from playground.wordpress.net.

      • The only place where we can run a site instance and keep it alive for a long time seems to be an "offscreen page". It's a special API available to extensions. They have access to DOM APIs.
      • Problem: We can't use the JavaScript client's startPlaygroundWeb() because there's eval() involved in exchanging messages with Playgound. That happens in Comlink.js library, I suspect it's because we pass callback functions around. Perhaps a refactoring would solve this. Anyway.
      • We can put an <iframe src="https://playground.wordpress.net"></iframe> in there, yay! We can even capture the /scope:9087313 path of the site opened in that iframe. Blueprint is passed via the URL fragment.
      • ✅ We can open that site via window.open(siteUrl)
      • ❌ We can't embed that site in an iframe. The service worker correctly receives the request from an iframe, but Chrome somehow prevents passing it from passing a message to the web worker running on the offscreen page.
      • Idea: use the extension message passing mechanism to work around that limitation.

    • Idea 2: Ship Playground with the extension

      • I bundled PHP, WordPress etc with the extension.
      • The extension's service worker handles fetch events in the same way as the service worker on playground.wordpress.net. It's very much like a web server.
      • That service worker handles requests to the extension URL, for example chrome-extension://fbalaiceeeoammejklginmckdfffgeje/wp-admin/post-new.php
      • ✅ WordPress loads when navigating directly to chrome-extension://fbalaiceeeoammejklginmckdfffgeje/wp-admin/post-new.php
        • ❌ No JavaScripts 😞
        • Challenge: WordPress wants a http://–based URL, gets redirects and pages wrong when served from chrome-extension://
        • Solution: Rewrite requests and responses. It's not perfect and there are likely better solutions, but it got us off the ground.
        • ❌ That page won't load inside an <iframe> embedded on another page.
      • ✅ It loaded in a "popup" for me! Could be a good middleground.
      • I got wp-login.php to load in a content script iframe after listing it under web_accessible_resources!
        • ❌ It loaded CSS files!
        • It still complained like this: Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self'".
      • ✅ wp-login.php loads via chrome.windows.create
        • ❌ No JavaScripts 😞 Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' 'wasm-unsafe-eval' 'inline-speculation-rules' http://localhost:* http://127.0.0.1:*". Either the 'unsafe-inline' keyword, a hash ('sha256-fzaeQ6PuVMQ+o48ATAh9SfYo1nWfwei03GKf11f6yUM='), or a nonce ('nonce-...') is required to enable inline execution.

    • Idea 3: Use sandbox

      • It doesn't seem like it could load extension pages, though, or use a service worker.
      • A sandboxed page won't have access to extension APIs, or direct access to non-sandboxed pages (it may communicate with them using postMessage()).
      • It comes from a non-secure origin so it can't register its own service worker. Clicking WordPress links, thus, would not work. Unless the extension service worker could intercept that somehow.
      • WordPress/wordpress-playground. Branch edit-visually-try-sandbox. Need to push from my laptop on wifi
        Inside the web page:

<iframe src="chrome-extension://hjaafimkfjnfdabpmpcilmpiemgmjcgb/sandbox-page.html?abc" sandbox="allow-same-origin allow-scripts allow-popups allow-forms"></iframe>

Manifest.json:

  "sandbox": {
    "pages": [
      "sandboxed-page.html"
    ]
  },
  "web_accessible_resources": [
    {
      "resources": [ "sandboxed-page.html" ],
      "matches": [ "<all_urls>" ]
    }
  ],
  "content_security_policy": {
    "sandbox": "sandbox allow-scripts allow-forms allow-popups allow-modals; script-src 'self' 'unsafe-inline' 'unsafe-eval'; child-src 'self' https://playground.wordpress.net; frame-src 'self' https://playground.wordpress.net;"
  },

		- The error says `Service worker is disabled because the context is sandboxed and lacks the 'allow-same-origin' flag.`
			- The iframe actually has that sandbox 
			- The manifest won't accept a allow-same-origin flag in content_security_policy > sandbox 😞  See [the doc](https://developer.chrome.com/docs/extensions/reference/manifest/sandbox) page:
				- You can specify your CSP value to restrict the sandbox even further, but it MUST include the "sandbox" directive and MUST NOT have the allow-same-origin token
			- I can, however, use the sandboxed page to iframe https://playground.wordpress.net directly on [GitHub.com](http://github.com/), which otherwise is impossible due to CSP restrictions!
				- The downside: The iframed service worker still won't work because of the same error:
						- `Failed to read the 'serviceWorker' property from 'Navigator': Service worker is disabled because the context is sandboxed and lacks the 'allow-same-origin' flag. `
			- ✅ However, **I can embed Playground on [GitHub.com](http://github.com/) by iframing a regular extension page and iframing Playground in there!**

Manifest.json:

    "content_security_policy": {
        "extension_pages": "script-src 'self' 'wasm-unsafe-eval'; default-src 'self' https://playground-editor-extension.pages.dev/; child-src 'self' https://playground.wordpress.net; frame-src 'self' https://playground.wordpress.net;"
    },
    "web_accessible_resources": [
        {
            "resources": ["regular-extension-page.html"],
            "matches": ["<all_urls>"]
        }
    ],

regular-extension-page.html:

<iframe
    src="https://playground.wordpress.net"
    sandbox="allow-same-origin allow-scripts allow-popups allow-forms"
></iframe>

	- Idea 4: listen to [playground.wordpress.net](http://playground.wordpress.net/) service worker messages and manually pass them to the web worker using chrome extension message passing
		- This is the one that worked out in the end. I just needed a secure origin allowed to register its own service workers.
		- Downside: You must be online before the first time you use the extension, which could be a problem if we try to reuse the same approach in webview-based mobile apps. Maybe, then, we need to skip the WebView and directly run PHP.wasm via a WASI runtime/library in these mobile apps instead?

---

One last challenge: Only run a single WASM instance of Playground and handle all the requests there. Do not spin a new instance for each site.

Conceptually, all the iframed Playgrounds would have to pass messages to a single worker.

• Regular content script -> <iframe src="loopback service worker"> -> intercept fetch events via window.onMessage() -> pass to extension service worker -> pass to offscreen page for handling
• Only this doesn't work, see the diagram: