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

Clarify steps when embed tag has unhandled MIME type #3876

Closed
qdot opened this Issue Aug 2, 2018 · 7 comments

Comments

3 participants
@qdot
Copy link
Member

qdot commented Aug 2, 2018

When an embed tag has an unhandled MIME type, there are no explicit steps about what to do. By the current setup steps, we'd end up at:

Otherwise, the content has no type and there can be no appropriate plugin for it.

But this doesn't explicitly say what to do with the content. In the case of object, we know to follow the fallback path (https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-object-element).

Testing across browsers using:

<html>
  <head>
  </head>
  <body>
    <embed src="https://example.com" type="application/whatever" />
  </body>
</html>
  • Chrome: Shows "Missing Plugin" UI
  • Safari: Shows "Missing Plugin" UI
  • Firefox: Currently parses src as a document type, will be dropping processing with no "Missing Plugin" UI once relevant bug lands
  • Edge: Parses src as document type and shows in embedded frame
@domenic

This comment has been minimized.

Copy link
Member

domenic commented Aug 9, 2018

Thanks for this catch. I agree we should add something that says to not load anything. Perhaps optionally displaying a "missing plugin" UI---it seems like that's not observable from JavaScript, and is just a UI thing, so that kind of optional feature is probably OK.

There's also a question as to whether browsers fire a load event in such cases. According to http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=6076 at least Chrome and Edge do not; not sure what your plans are for Firefox after the change.

I will work on a spec patch for this, but can you work on tests for the load event thing?

domenic added a commit that referenced this issue Aug 9, 2018

State what happens to <embed> with an unhandled MIME type
Also rewrites the algorithm in more modern style, which clears up some
confusion around "resources" and load events and such.

Fixes #3876.
@annevk

This comment has been minimized.

Copy link
Member

annevk commented Aug 10, 2018

Wouldn't it be observable through CSS-related APIs?

@domenic

This comment has been minimized.

Copy link
Member

domenic commented Aug 10, 2018

I don't think so, because the width/height is always the same (300x150) and for non-SVG documents there's no way of accessing the nested browsing context or Document (indeed, such a nested browsing context does not exist, at least per spec).

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Aug 14, 2018

Hmm, in Firefox with data:text/html,x<embed src=https://software.hixie.ch/utilities/js/live-dom-viewer/flash>x it ends up not being rendered at all.

@domenic

This comment has been minimized.

Copy link
Member

domenic commented Aug 14, 2018

I don't have my computer with Nightly at the moment, but if so, yeah, that's not good... Firefox should probably create a 300x150 box like all the other engines do. @qdot?

@domenic

This comment has been minimized.

Copy link
Member

domenic commented Aug 14, 2018

Interestingly, the existing spec says (hidden after the normative algorithm):

The embed element has no fallback content. If the user agent can't find a suitable plugin when attempting to find and instantiate one for the algorithm above, then the user agent must use a default plugin. This default could be as simple as saying "Unsupported Format".

domenic added a commit that referenced this issue Aug 14, 2018

Consolidate the "display an unsupported plugin" message
This was previously outside the flow of the algorithm, causing it to be missed in #3876. As such I think it makes this whole change editorial?

Also fixed a problem where we were taking the "otherwise" path for content-type headers that indicate plugins we don't support
@qdot

This comment has been minimized.

Copy link
Member

qdot commented Aug 14, 2018

Ah, ok, in the bugzilla bug for firefox relating to this (https://bugzilla.mozilla.org/show_bug.cgi?id=1473833), I pushed execution down the object plugin logic path, which goes to object fallback. Didn't realize that was suppose to go to "unsupported plugin". That'll take a bit more logic on our end but I think is doable.

domenic added a commit that referenced this issue Aug 17, 2018

State what happens to <embed> with an unhandled MIME type
Also rewrites the algorithm in more modern style, which clears up some
confusion around "resources" and load events and such.

Fixes #3876.

domenic added a commit that referenced this issue Aug 17, 2018

Consolidate the "display an unsupported plugin" message
This was previously outside the flow of the algorithm, causing it to be missed in #3876. As such I think it makes this whole change editorial?

Also fixed a problem where we were taking the "otherwise" path for content-type headers that indicate plugins we don't support

domenic added a commit that referenced this issue Aug 20, 2018

Clarify and tweak <embed> processing model
This rewrites the <embed> processing model in a more modern style, along
the way clarifying a few things and making some minor normative changes.

* Fixes #3876 by colocating the text about notification of there being
  no plugin into the main algorithm, where it is more easily noticed.
* Changes to not fire load events when no plugin is loaded.
* Changes the SVG browsing context to get unloaded when a non-SVG is
  being displayed.

With regard to these normative changes, browsers behave inconsistently.
Indeed, they behave inconsistently in general with regard to lots of
features of <embed> and <object>; see
https://github.com/whatwg/html/labels/topic%3A%20embed%20and%20object.
We leave a more comprehensive overhaul, including with a testing story,
for later work. This revision just provides a basis for that future
work.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment