Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTMLImageElement.src in about:blank documents #9855

Closed
josepharhar opened this issue Oct 13, 2023 · 2 comments
Closed

HTMLImageElement.src in about:blank documents #9855

josepharhar opened this issue Oct 13, 2023 · 2 comments

Comments

@josepharhar
Copy link
Contributor

josepharhar commented Oct 13, 2023

What is the issue with the HTML Standard?

Chrome, Firefox, and Safari all have special behavior in HTMLImageElement.src (and other URL-related reflected attributes?) which "completes" the URL from the string provided in the actual attribute.

At http://example.com, we have the following behavior which is compatible across these browsers:

// At http://example.com/
const img = document.createElement('img');
img.src = '/foo';
img.src; // returns "http://example.com/foo"
img.getAttribute('src'); // returns "/foo"

I'm not sure if this behavior is specified or not. In chrome we have a "URL" IDL attribute in the IDL for src which generates code to do this behavior.

In about:blank documents, however, Chrome returns an empty string, I think because it considers the URL to not be valid. Firefox and Safari just return what was assigned into the attribute:

// At about:blank
const img = document.createElement('img');
img.src = '/foo';
// Chrome returns ""
// Firefox+Safari return "/foo"
img.src;

What is the desired behavior here? Should I just make Chrome return whatever the actual attribute value is for non-valid URLs, like in about:blank documents?

@domenic
Copy link
Member

domenic commented Oct 15, 2023

This is well-specified here, under the "If a reflected IDL attribute has the type USVString" case. It has nothing to do with about:blank documents in particular, just about URL parsing: parsing /foo against about:blank results in a parse failure. Because the result of step 4.2 is failure, we fall back to step 5, so Firefox and Safari's behavior is correct.

In particular, this means the bug is in Chromium's URL reflected attribute thing. This maybe the source of some of Chrome's Interop 2023 failures on URLs. /cc @hayatoito No, nevermind, HTMLAnchorElement does not use [Reflect, URL] in this way.

I hope this helps!

@domenic domenic closed this as completed Oct 15, 2023
@josepharhar
Copy link
Contributor Author

Thanks Domenic! I opened a crbug here: https://bugs.chromium.org/p/chromium/issues/detail?id=1493146
I couldn't easily figure out how the generated bindings code works myself, so hopefully someone else can help out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants