Handle cases when location.protocol is `about:` or `data:` #13226

CNSeniorious000 · 2024-12-23T06:03:54Z

Describe the problem

I am using svelte in several embedded webviews. I used to have to run a static file server before bundleStrategy: 'inline' became available yesterday.

Normally (if we click this html file) the url will start with file://, and everything works fine.

But In the webview implementation I use the url is a data url, and hydration always fails because of:

Uncaught TypeError: Failed to construct 'URL': Invalid URL
    at data:text/html;chars…8L2h0bWw+Cg==:16:13

In another case, I want to parse metadata from an url using an iframe, but sveltekit apps always fail to hydrate because of a similar error:

Uncaught TypeError: Failed to construct 'URL': Invalid URL
    at about:blank:16:13

Describe the proposed solution

Sveltekit always generates

  <body data-sveltekit-preload-data="hover">
    <div style="display: contents">
      <script>
        {
          __sveltekit_1bknoa9 = {
            base: new URL('.', location).pathname.slice(0, -1)
        };

where new URL('.', location) will fail when location.protocol is data:// or about://

Alternatives considered

No response

Importance

would make my life easier

Additional Information

No response

The text was updated successfully, but these errors were encountered:

CNSeniorious000 · 2024-12-23T06:11:32Z

kit/packages/kit/src/runtime/server/page/render.js

Lines 103 to 113 in 64c8e04

    
           	// resolve e.g. '../..' against current location, then remove trailing slash 
        
           	base_expression = `new URL(${s(base)}, location).pathname.slice(0, -1)`; 
        
           	if (!paths.assets || (paths.assets[0] === '/' && paths.assets !== SVELTE_KIT_ASSETS)) { 
        
           		assets = base; 
        
           	} 
        
           } else if (options.hash_routing) { 
        
           	// we have to assume that we're in the right place 
        
           	base_expression = "new URL('.', location).pathname.slice(0, -1)"; 
        
           }

An ugly fix would be

- `new URL(${s(base)}, location).pathname.slice(0, -1)`
+ `["about:", "data:"].includes(location.protocol) ? `${s(base)} : new URL(${s(base)}, location).pathname.slice(0, -1)`

- new URL('.', location).pathname.slice(0, -1)
+ ["about:", "data:"].includes(location.protocol) ? "" : new URL('.', location).pathname.slice(0, -1)

eltigerchino · 2024-12-23T08:47:03Z

You are welcome to open a pull request. Are there any other protocols we need to consider? Maybe we can create a set and search that.

CNSeniorious000 · 2024-12-23T15:24:11Z

I think maybe ftp:? But it doesn't disrupt the current implementation. The only issues seem to arise with data: and about:.

eltigerchino · 2025-01-10T07:19:04Z

Did some investigation and there seems to be two ways of embedding SvelteKit through HTML text:

1. iframe srcdoc="..."

The document will have an embedded URL of about:srcdoc which is an invalid URL base.

2. iframe src="data:text/html;charset=utf-8,..."

The document will have an embedded URL of data:text/html... which is an invalid URL base.

Overall, there's a number of changes we need to make to avoid the "invalid base URL" error when constructing a new URL object to improve embedding SvelteKit apps as HTML text.

kit/packages/kit/src/runtime/server/page/render.js

Line 105 in 5b667e4

base_expression = `new URL(${s(base)}, location).pathname.slice(0, -1)`;

kit/packages/kit/src/runtime/server/page/render.js

Line 112 in 5b667e4

base_expression = "new URL('.', location).pathname.slice(0, -1)";

kit/packages/kit/src/runtime/client/utils.js

Lines 15 to 22 in 5b667e4

    
           let baseURI = document.baseURI; 
        
           if (!baseURI) { 
        
           	const baseTags = document.getElementsByTagName('base'); 
        
           	baseURI = baseTags.length ? baseTags[0].href : document.URL; 
        
           } 
        
           return new URL(url, baseURI);

kit/packages/kit/src/runtime/client/utils.js

Line 132 in 5b667e4

    
           url = new URL(a instanceof SVGAElement ? a.href.baseVal : a.href, document.baseURI);

kit/packages/kit/src/runtime/client/client.js

Line 1854 in 5b667e4

const { href } = new URL(resource, location.href);

kit/packages/kit/src/runtime/client/client.js

Line 2504 in 5b667e4

await native_navigation(new URL(error.location, location.href));

cc: @kran6a

Also, when using a hash router, it's possible for the page to infinitely refresh due to the embedded URL pathname not passing any of the conditions below (#13287):

kit/packages/kit/src/runtime/client/utils.js

Lines 313 to 324 in 5b667e4

    
           if (hash_routing) { 
        
           	if (url.pathname === base + '/') { 
        
           		return false; 
        
           	} 
        
           	// be lenient if serving from filesystem 
        
           	if (url.protocol === 'file:' && url.pathname.replace(/\/[^/]+\.html?$/, '') === base) { 
        
           		return false; 
        
           	} 
        
           	return true; 
        
           }

Fortunately, we can check if location.url.origin === 'null' to detect non-http/https URLs or if the kit.config.embedded option is set and perhaps handle these situations more gracefully.

kran6a · 2025-01-20T20:08:11Z

I applied this patch on my node_modules and it works for my use-case. There are no invalid base URL errors and no infinite reloads.
Absolute links work, relative links won't ever work because I am using an iframe with srcdoc which makes relative URL take the parent base.

One strange thing I noticed that also broke when migrating widgets from raw svelte (bundling to a single .js file then inlining it into an HTML shell) to sveltekit is that previously I injected some classes into the iframe from the host website via

iframe_element.contentWindow.props = {some_class: Class}; //Class is a class definition, not an instance

These classes use runes and this approach worked on svelte but reactivity broke after transitioning to sveltekit.
Importing the classes from the widget code fixes reactivity but the point of injecting those classes is that widgets don't need to bundle them to reduce their size, dependencies and maintenance as they all will use the most recent version of those classes.
I am not attempting to achieve cross-document reactivity, classes are instanced and meant to be reactive only within the iframe.
I am a bit puzzled on why this does not work. The class state is updated correctly and if you trigger a reload somehow (e.g: navigating to another route and then back) you can see the updated state correctly but reactivity is still nonexistant.

diff --git a/node_modules/@sveltejs/kit/src/runtime/client/utils.js b/node_modules/@sveltejs/kit/src/runtime/client/utils.js
index 28a06d8..24b6ee7 100644
--- a/node_modules/@sveltejs/kit/src/runtime/client/utils.js
+++ b/node_modules/@sveltejs/kit/src/runtime/client/utils.js
@@ -311,6 +311,9 @@ export function is_external_url(url, base, hash_routing) {
 	}
 
 	if (hash_routing) {
+		if (url.protocol === "about:" || url.protocol === "data:"){
+			return false;
+		}
 		if (url.pathname === base + '/' || url.pathname === base + '/index.html') {
 			return false;
 		}
diff --git a/node_modules/@sveltejs/kit/src/runtime/server/page/render.js b/node_modules/@sveltejs/kit/src/runtime/server/page/render.js
index d8fbe32..82867e0 100644
--- a/node_modules/@sveltejs/kit/src/runtime/server/page/render.js
+++ b/node_modules/@sveltejs/kit/src/runtime/server/page/render.js
@@ -109,7 +109,7 @@ export async function render_response({
 			}
 		} else if (options.hash_routing) {
 			// we have to assume that we're in the right place
-			base_expression = "new URL('.', location).pathname.slice(0, -1)";
+			base_expression = "location.protocol === 'about:' || location.protocol === 'data:' ? '' : new URL('.', location.protocol).pathname.slice(0, -1)";
 		}
 	}

CNSeniorious000 changed the title ~~Handle cases when location.protocal is about: or data:~~ Handle cases when location.protocol is about: or data: Dec 23, 2024

CNSeniorious000 mentioned this issue Dec 23, 2024

fix: avoid errors when constructing the base path in certain edge cases #13231

Closed

6 tasks

eltigerchino mentioned this issue Jan 10, 2025

fix: correctly detect internal links when hash router is used #13296

Merged

6 tasks

eltigerchino added the bug Something isn't working label Jan 10, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Handle cases when location.protocol is `about:` or `data:` #13226

Handle cases when location.protocol is `about:` or `data:` #13226

CNSeniorious000 commented Dec 23, 2024 •

edited

Loading

CNSeniorious000 commented Dec 23, 2024 •

edited

Loading

eltigerchino commented Dec 23, 2024 •

edited

Loading

CNSeniorious000 commented Dec 23, 2024

eltigerchino commented Jan 10, 2025 •

edited

Loading

kran6a commented Jan 20, 2025

Handle cases when location.protocol is about: or data: #13226

Handle cases when location.protocol is about: or data: #13226

Comments

CNSeniorious000 commented Dec 23, 2024 • edited Loading

Describe the problem

Describe the proposed solution

Alternatives considered

Importance

Additional Information

CNSeniorious000 commented Dec 23, 2024 • edited Loading

eltigerchino commented Dec 23, 2024 • edited Loading

CNSeniorious000 commented Dec 23, 2024

eltigerchino commented Jan 10, 2025 • edited Loading

1. iframe srcdoc="..."

2. iframe src="data:text/html;charset=utf-8,..."

kran6a commented Jan 20, 2025

Handle cases when location.protocol is `about:` or `data:` #13226

Handle cases when location.protocol is `about:` or `data:` #13226

CNSeniorious000 commented Dec 23, 2024 •

edited

Loading

CNSeniorious000 commented Dec 23, 2024 •

edited

Loading

eltigerchino commented Dec 23, 2024 •

edited

Loading

eltigerchino commented Jan 10, 2025 •

edited

Loading