Missing CSS and images because the Gutenberg iframe isn't controlled by the service worker #646

Lovor01 · 2023-09-21T07:15:04Z

This happens only in https://playground.wordpress.net/, when run locally as VS code extension, the issue does not appear.

Block inserter "+" icon is not styled; some other UI elements (like buttons when inserting new image block, buttons on starter template on columns block, etc) are not styled as well; when inserting new image and uploading it through interface, the image does not show in block editor.

Tested on Firefox developer version 118 b9 and Chrome dev version 118 on Windows 10.

Steps to reproduce:
Start new WP instance in playground. Create new post, insert image from local file.

Network inspector shows a bunch of 404s for URLs like https://playground.wordpress.net/scope:0.5858414608182674/wp-includes/css/dist/block-editor/style.min.css?ver=6.3 which originate from an iframe rendered by Gutenberg. That iframe has src="blob:https://playground.wordpress.net/9c82f60a-1f1e-4abe-adde-6b5b62f51043" and I'm almost certain it's considered cross-origin and thus the requests it issues are not handled by the service worker. It's this issue all over again:

#42

I'm not sure what the fix is yet.

adamziel · 2023-09-29T09:03:19Z

Here's what I found:

The iframe has the same origin as the parent window
The iframe still isn't being controlled by the service worker
The iframe can't register its own service worker

Here's the script I used to verify the above:

async function init() {
    // Register a service worker
    await navigator.serviceWorker.register('/sw.js', { scope: '/' });
    console.log('Registration successful');
    // Reload the page after the first time this script runs

    // Now, confirm the top-level script is controlled by the service worker
    console.log("I'm an top-level script", {
        origin: window.location.origin,
        swController: navigator.serviceWorker.controller
    });

    // Let's create a blob-based iframe and check if it's controlled by the service worker
    const blob = new Blob([`
    <html>
        <body>
            <h1>Test iframe</h1>
            <script>
                console.log("I'm an iframe", {
                    origin: window.location.origin,
                    swController: navigator.serviceWorker.controller,
                    protocol: window.location.protocol
                });
            </script>
        </body>
    </html>
    `], { type: 'text/html' });
    const blobUrl = URL.createObjectURL(blob);
    const iframe = document.createElement('iframe');
    document.body.appendChild(iframe);
    iframe.src = blobUrl;

    // And sadly, the iframe is not controlled by the service worker :-(
}
init();

adamziel · 2023-09-29T09:12:20Z

To sum it all up:

An iframe using src set to a binary blob isn't controlled by a service worker
An iframe using srcdoc had a null origin and also isn't controlled by a service worker
Ditto for using a data URL
An iframe loaded using a regular src="" URL worked well

URL-based src like src="/doc.html" seems to be the only way forward. Or am I missing something? cc @dmsnell

@ellatrix can you remember what was the rationale behind using a blob vs a URL? Was it saving an extra request and figuring out the right file path? Would it be viable to create an extension point to enable forcing src="file.html" in Playground?

dmsnell · 2023-09-29T22:32:06Z

no idea @adamziel, though I think the blob has memory implications for Gutenberg.

ellatrix · 2023-10-02T13:27:46Z

We switched to blob to fix the origin issue, it's also a bit cleaner that srcDoc. Why does it need to be controlled by the service worker? It's purely added in JS, nothing server side? Are we talking about the editor content iframe or something else? I thought everything was working fine?

adamziel · 2023-10-02T13:43:59Z

@ellatrix the root problem was always the service worker not handling the requests from the editor content iframe – like loading style.css for specific blocks. When it does, we say the iframe is controlled by the service worker.

In our chat I somehow reached a wrong conclusion. I thought that the iframe only needs to have the same origin to be controlled. It doesn't. The blob-based editor content iframe now has the same origin as the top-level page, but it still isn't controlled. The only way I was able to make it controlled was by using a path-based src like src="/document.html"

adamziel · 2023-10-05T14:16:12Z

We'd need to revert WordPress/gutenberg#50875 in Gutenberg, but then the original issue it solved would return:

The problem with srcDoc is that window.location is not filled, so relative hash links will trigger a navigation change and reload the page. It would also remove the need for a hack in WP playground.

For now I'll see if I can patch this in Playground to fix all the 404s, and then let's see what a proper solution would look like. cc @ellatrix

Edit: This is more difficult than just swapping src={blob} with src={url} because the initial document now loads all related CSS assets. Hm.

Edit 2: This worked for me locally:

In WordPress/Gutenberg:

src: '/wp-includes/empty.html?doc='+encodeURIComponent(renderToString( styleAssets ))

In empty.html:

<!doctype html>
<script>document.write(decodeURIComponent(window.location.search.substring(5)))</script>

However, this creates an XSS vulnerabilty. It's fine for Playground since you can run custom code anyway, but it wouldn't work for WordPress core at all. I do not see a single solution that would suit both WordPress core and Playground here and we may be stuck with patching that part of WordPress until there is one.

bfintal · 2023-10-08T15:19:46Z

Encountered this as well during the brief period the Live Preview button was in the Plugin Directory. A bunch of 404s and unstyled content of the Block Editor.

Was using latest Arc on latest MacOS.

Would recommend making this urgent issue.

ellatrix · 2023-10-09T07:56:12Z

URL-based src like src="/doc.html" seems to be the only way forward. Or am I missing something? cc @dmsnell

It's using a blob URL, no? 😉

adamziel · 2023-10-09T08:04:47Z

Sure it does @ellatrix. Let's call them HTTP URLs and blob URLs then :p

…ce worker Fixes #646 Patches the block editor to use a special ControlledIframe component instead of a regular HTML "iframe" element. The goal is to make the iframe use a plain HTTP URL instead of srcDoc, blob URL and other variations. Why? In Playground, the editor iframe needs to be controlled by Playground's service worker so it can serve CSS and other static assets. Otherwise all the requests originating in that iframe will yield 404s. However, different WordPress versions use a variety of iframe techniques that result in a non-controlled iframe: * 6.3 uses a binary blob URL and the frame isn't controlled by a service worker * <= 6.2 uses srcdoc had a null origin and the frame isn't controlled by a service worker * Other dynamic techniques, such as using a data URL, also fail to produce a controlled iframe HTTP URL src like src="/doc.html" seems to be the only way to create a controlled iframe. And so, this commit ensures that the block editor iframe uses a plain HTTP URL regardless of the WordPress version. Related: WordPress/gutenberg#55152

adamziel · 2023-10-09T09:11:25Z

Short-term fix coming in #668
Long-term fix is being explored in the Gutenberg repo at WordPress/gutenberg#55152

@ellatrix

…ce worker (#668) ## What is this PR doing? Patches the block editor to use a special ControlledIframe component instead of a regular HTML "iframe" element. The goal is to make the iframe use a plain HTTP URL instead of srcDoc, blob URL and other variations. Normally, the patch applied here would be a huge maintenance burden over time. However, @ellatrix explores fixing the issue upstream [in the Gutenberg repo](#646). Once her PR is merged, the patch here will only be needed for a known and limited set of WordPress and Gutenberg versions and will not require ongoing reconciliation with new WP/GB releases. Fixes #646 ## What problem is it solving? In Playground, the editor iframe needs to be controlled by Playground's service worker so it can serve CSS and other static assets. Otherwise all the requests originating in that iframe will yield 404s. However, different WordPress versions use a variety of iframe techniques that result in a non-controlled iframe: * 6.3 uses a binary blob URL and the frame isn't controlled by a service worker * <= 6.2 uses srcdoc had a null origin and the frame isn't controlled by a service worker * Other dynamic techniques, such as using a data URL, also fail to produce a controlled iframe HTTP URL src like src="/doc.html" seems to be the only way to create a controlled iframe. And so, this commit ensures that the block editor iframe uses a plain HTTP URL regardless of the WordPress version. Once WordPress/gutenberg#55152 lands, this will just work in WordPress 6.4 and new Gutenberg releases. ## Testing Instructions Run `npm run dev` Then, confirm the inserter is nicely styled and there are no CSS-related 404s in the network tools. Test the following editors: * Post editor http://localhost:5400/website-server/?url=/wp-admin/post-new.php * Site editor http://localhost:5400/website-server/?url=/wp-admin/site-editor.php * For all supported WordPress versions * With and without the Gutenberg plugin (`&plugin=gutenberg`) ## Related * https://bugs.chromium.org/p/chromium/issues/detail?id=880768 * https://bugzilla.mozilla.org/show_bug.cgi?id=1293277 * w3c/ServiceWorker#765 * #42 * b7ca737

adamziel · 2023-10-09T09:15:03Z

#668 just landed and I'm about to deploy it to playground.wordpress.net. Let's keep this issue open until the upstream Gutenberg PR gets resolved in one way or another.

@ellatrix

…ce worker (#668) ## What is this PR doing? Patches the block editor to use a special ControlledIframe component instead of a regular HTML "iframe" element. The goal is to make the iframe use a plain HTTP URL instead of srcDoc, blob URL and other variations. Normally, the patch applied here would be a huge maintenance burden over time. However, @ellatrix explores fixing the issue upstream [in the Gutenberg repo](#646). Once her PR is merged, the patch here will only be needed for a known and limited set of WordPress and Gutenberg versions and will not require ongoing reconciliation with new WP/GB releases. Fixes #646 ## What problem is it solving? In Playground, the editor iframe needs to be controlled by Playground's service worker so it can serve CSS and other static assets. Otherwise all the requests originating in that iframe will yield 404s. However, different WordPress versions use a variety of iframe techniques that result in a non-controlled iframe: * 6.3 uses a binary blob URL and the frame isn't controlled by a service worker * <= 6.2 uses srcdoc had a null origin and the frame isn't controlled by a service worker * Other dynamic techniques, such as using a data URL, also fail to produce a controlled iframe HTTP URL src like src="/doc.html" seems to be the only way to create a controlled iframe. And so, this commit ensures that the block editor iframe uses a plain HTTP URL regardless of the WordPress version. Once WordPress/gutenberg#55152 lands, this will just work in WordPress 6.4 and new Gutenberg releases. ## Testing Instructions Run `npm run dev` Then, confirm the inserter is nicely styled and there are no CSS-related 404s in the network tools. Test the following editors: * Post editor http://localhost:5400/website-server/?url=/wp-admin/post-new.php * Site editor http://localhost:5400/website-server/?url=/wp-admin/site-editor.php * For all supported WordPress versions * With and without the Gutenberg plugin (`&plugin=gutenberg`) ## Related * https://bugs.chromium.org/p/chromium/issues/detail?id=880768 * https://bugzilla.mozilla.org/show_bug.cgi?id=1293277 * w3c/ServiceWorker#765 * #42 * b7ca737

This PR moves applying a WordPress patch from the Dockerfile, where WP is built into a `.data` file, to JavaScript, where it can be applied to any arbitrary WordPress installation. This is needed to patch WordPress branches in Pull Request previewer. See #700. Testing instructions: 1. Run Playground with `npm run start` 2. Go to the block editor 3. Confirm that inserter's CSS is loaded (black + icon) 4. Install the Gutenberg plugin 5. Confirm that inserter's CSS is still loaded Related to #668, #646.

…ile (#703) This PR moves applying a WordPress patch from the Dockerfile, where WP is built into a `.data` file, to JavaScript, where it can be applied to any arbitrary WordPress installation. This is needed to patch WordPress branches in Pull Request previewer. See #700. ## Testing instructions: 1. Run Playground with `npm run start` 2. Go to the block editor 3. Confirm that inserter's CSS is loaded (black + icon) 4. Install the Gutenberg plugin 5. Confirm that inserter's CSS is still loaded Related to #668, #646.

adamziel added the [Type] Bug An existing feature does not function as intended label Sep 28, 2023

adamziel added the [Priority] High label Sep 29, 2023

dmsnell mentioned this issue Sep 29, 2023

Error enabling "Custom fields" panel in post editor preferences #645

Closed

adamziel mentioned this issue Oct 4, 2023

Stable web version #653

Closed

10 tasks

adamziel changed the title ~~CSS missing, images missing~~ Missing CSS and images because the Gutenberg iframe isn't controlled by the service worker Oct 6, 2023

adamziel added the [Aspect] Service Worker label Oct 6, 2023

adamziel mentioned this issue Oct 9, 2023

Iframe: try proper URL instead of blob WordPress/gutenberg#55152

Open

adamziel mentioned this issue Oct 9, 2023

[Patch WordPress] Ensure block editor iframe is controlled by a service worker #668

Merged

adamziel closed this as completed in #668 Oct 9, 2023

adamziel reopened this Oct 9, 2023

adamziel mentioned this issue Oct 16, 2023

WP: Apply the "controlled iframe" patch in JavaScript, not in Dockerfile #703

Merged

adamziel mentioned this issue Nov 22, 2023

WordPress feature parity #764

Open

11 tasks

This was referenced Jan 12, 2024

Browser: Patch Gutenberg on site import #938

Merged

Issue with cross-origin isolation #952

Open

adamziel added this to the Zero Crashes milestone Feb 29, 2024

github-project-automation bot added this to Playground Board Feb 29, 2024

gigitux mentioned this issue Jun 5, 2024

Multiple 404 and 428 errors #1485

Open

adamziel added the [Type] Project label Jun 28, 2024

adamziel moved this to Project: Up Soon in Playground Board Jun 30, 2024

adamziel moved this from Project: Triage to Project: Up soon in Playground Board Jul 1, 2024

adamziel moved this from Project: Up soon to Inbox in Playground Board Jul 1, 2024

adamziel removed this from the Zero Crashes milestone Nov 28, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Missing CSS and images because the Gutenberg iframe isn't controlled by the service worker #646

Missing CSS and images because the Gutenberg iframe isn't controlled by the service worker #646

Lovor01 commented Sep 21, 2023 •

edited by adamziel

Loading

code-flow commented Sep 27, 2023

adamziel commented Sep 28, 2023

adamziel commented Sep 29, 2023

adamziel commented Sep 29, 2023 •

edited

Loading

dmsnell commented Sep 29, 2023

ellatrix commented Oct 2, 2023

adamziel commented Oct 2, 2023 •

edited

Loading

adamziel commented Oct 5, 2023 •

edited

Loading

bfintal commented Oct 8, 2023 •

edited

Loading

ellatrix commented Oct 9, 2023

adamziel commented Oct 9, 2023

adamziel commented Oct 9, 2023

adamziel commented Oct 9, 2023 •

edited

Loading

Missing CSS and images because the Gutenberg iframe isn't controlled by the service worker #646

Missing CSS and images because the Gutenberg iframe isn't controlled by the service worker #646

Comments

Lovor01 commented Sep 21, 2023 • edited by adamziel Loading

Related

code-flow commented Sep 27, 2023

adamziel commented Sep 28, 2023

adamziel commented Sep 29, 2023

adamziel commented Sep 29, 2023 • edited Loading

dmsnell commented Sep 29, 2023

ellatrix commented Oct 2, 2023

adamziel commented Oct 2, 2023 • edited Loading

adamziel commented Oct 5, 2023 • edited Loading

bfintal commented Oct 8, 2023 • edited Loading

ellatrix commented Oct 9, 2023

adamziel commented Oct 9, 2023

adamziel commented Oct 9, 2023

adamziel commented Oct 9, 2023 • edited Loading

Lovor01 commented Sep 21, 2023 •

edited by adamziel

Loading

adamziel commented Sep 29, 2023 •

edited

Loading

adamziel commented Oct 2, 2023 •

edited

Loading

adamziel commented Oct 5, 2023 •

edited

Loading

bfintal commented Oct 8, 2023 •

edited

Loading

adamziel commented Oct 9, 2023 •

edited

Loading