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

Should <object data=...> support javascript: URLs? #10719

Open
mbrodesser-Igalia opened this issue Oct 24, 2024 · 7 comments
Open

Should <object data=...> support javascript: URLs? #10719

mbrodesser-Igalia opened this issue Oct 24, 2024 · 7 comments
Labels
document conformance interop Implementations are not interoperable with each other topic: embed and object

Comments

@mbrodesser-Igalia
Copy link
Member

What is the issue with the HTML Standard?

Browsers' behavior differs for it. E.g. for https://jsfiddle.net/6bv9xogk/, Chrome and WebKit treat javascript: URLs as no-ops, Firefox executes the script.

The object element's data attribute is specified 1 as a "valid non-empty URL potentially surrounded by spaces" 2. The iframe element's src attribute 3 has the same type. All major browsers support javascript: URLs in iframes. So per spec, iframe elements and object elements should behave the same.

I couldn't figure out yet whether 2 includes javascript: URLs.

Footnotes

  1. https://html.spec.whatwg.org/multipage/iframe-embed-object.html#attr-object-data

  2. https://html.spec.whatwg.org/multipage/urls-and-fetching.html#valid-non-empty-url-potentially-surrounded-by-spaces 2

  3. https://html.spec.whatwg.org/multipage/iframe-embed-object.html#dom-iframe-src

@annevk
Copy link
Member

annevk commented Oct 24, 2024

That's the type for writing HTML documents which isn't really relevant to user agents. The processing requirements for the elements are quite different.

The object element is supposed to go through fetch (unless you navigate it directly) which ends up failing on a scheme like "javascript".

So Chromium and WebKit are correct. Here's an improved test:

https://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cp%3EYou%20should%20see%20PASS%20below%3A%0A%3Cp%3E%3Cobject%20data%3Djavascript%3Aalert(%27FAIL%27)%3EPASS%3C%2Fobject%3E

@annevk
Copy link
Member

annevk commented Oct 24, 2024

cc @farre

@annevk annevk added the interop Implementations are not interoperable with each other label Oct 24, 2024
@mbrodesser-Igalia
Copy link
Member Author

That's the type for writing HTML documents which isn't really relevant to user agents.

Which type? How is it not relevant to user agents?

The processing requirements for the elements are quite different.

The object element is supposed to go through fetch (unless you navigate it directly)

What means navigating it directly? Isn't the latter happening in the example?

which ends up failing on a scheme like "javascript".

So Chromium and WebKit are correct.

Is that backed up by the spec? It's not obvious.

Here's an improved test:

https://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cp%3EYou%20should%20see%20PASS%20below%3A%0A%3Cp%3E%3Cobject%20data%3Djavascript%3Aalert(%27FAIL%27)%3EPASS%3C%2Fobject%3E

@zcorpan
Copy link
Member

zcorpan commented Oct 29, 2024

How is it not relevant to user agents?

See https://html.spec.whatwg.org/multipage/infrastructure.html#conformance-classes

The text

The data attribute specifies the URL of the resource. It must be present, and must contain a valid non-empty URL potentially surrounded by spaces.

...applies to documents.

What means navigating it directly?

If there already is a child browsing context for the object element, you can navigate it by clicking a link or setting location.href. Example: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13227

Is that backed up by the spec?

The algorithm at https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-object-element:~:text=Whenever%20one%20of%20the%20following%20conditions%20occur: step 3.4 invokes fetch, then based on the response will either create a child navigable in step 9 or go to the image path or fallback path. A javascript: URL in data will fail to fetch (demo) and so should go to the fallback path.

@mbrodesser-Igalia
Copy link
Member Author

How is it not relevant to user agents?

See https://html.spec.whatwg.org/multipage/infrastructure.html#conformance-classes

The text

The data attribute specifies the URL of the resource. It must be present, and must contain a valid non-empty URL potentially surrounded by spaces.

...applies to documents.

That applies to the iframe element's src attribute too 1. So it seems per spec, neither iframe's src attribute, nor object's data attribute may be used with javascript: URLs. Or did I miss something?

What means navigating it directly?

If there already is a child browsing context for the object element, you can navigate it by clicking a link or setting location.href. Example: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13227

Is that backed up by the spec?

The algorithm at https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-object-element:~:text=Whenever%20one%20of%20the%20following%20conditions%20occur: step 3.4 invokes fetch, then based on the response will either create a child navigable in step 9 or go to the image path or fallback path. A javascript: URL in data will fail to fetch (demo) and so should go to the fallback path.

Correct.

Footnotes

  1. https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-iframe-element:dom-iframe-src

@zcorpan
Copy link
Member

zcorpan commented Oct 30, 2024

That applies to the iframe element's src attribute too 1. So it seems per spec, neither iframe's src attribute, nor object's data attribute may be used with javascript: URLs. Or did I miss something?

A javascript: URL is a valid URL per https://url.spec.whatwg.org/#absolute-url-string , so it's conforming for documents to use such URLs for both <object data> and <iframe src>. This doesn't imply anything about what a UA is required to do.

I suppose we could change the document conformance rules to disallow javascript: URLs everywhere except <iframe src>, <a href>, and a few others. But I think it's likely not worth the extra complexity.

@annevk
Copy link
Member

annevk commented Nov 5, 2024

@sideshowbarker might have an opinion on conformance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
document conformance interop Implementations are not interoperable with each other topic: embed and object
Development

No branches or pull requests

3 participants