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

[mbrodesser-Igalia]

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 ¹ as a "valid non-empty URL potentially surrounded by spaces" ². The iframe element's src attribute ³ 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 ² 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 ↩ ↩²

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

[annevk]

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]

cc @farre

[mbrodesser-Igalia]

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]

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]

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 ¹. 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]

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]

@sideshowbarker might have an opinion on conformance.