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.

Sign up for GitHub

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

Jump to bottom

Clarify steps when embed tag has unhandled MIME type #3876

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

Clarify steps when embed tag has unhandled MIME type #3876

qdot opened this issue Aug 2, 2018 · 7 comments
Labels
clarification Standard could be clearer topic: embed and object

Comments

@qdot
Copy link

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
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
@domenic
State what happens to <embed> with an unhandled MIME type
e14187c 
Also rewrites the algorithm in more modern style, which clears up some
confusion around "resources" and load events and such.

Fixes #3876.
@domenic domenic mentioned this issue Aug 9, 2018
Merged
@annevk
Copy link
Member

annevk commented Aug 10, 2018

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

@domenic
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
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
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
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 domenic mentioned this issue Aug 14, 2018
Open
@domenic domenic added the clarification Standard could be clearer label Aug 14, 2018
domenic added a commit that referenced this issue Aug 14, 2018
@domenic
Consolidate the "display an unsupported plugin" message
77b9805 
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
Copy link
Author

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
@domenic
State what happens to <embed> with an unhandled MIME type
e3e5d7c 
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
@domenic
Consolidate the "display an unsupported plugin" message
f9c047e 
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
@domenic
Clarify and tweak <embed> processing model
d0b0925 
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.
@scottaohara scottaohara mentioned this issue Aug 28, 2018
Closed
mustaqahmed pushed a commit to mustaqahmed/html that referenced this issue Feb 15, 2019
@domenic @mustaqahmed
Clarify and tweak <embed> processing model
aa7e918 
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 whatwg#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.
mustaqahmed pushed a commit to mustaqahmed/html that referenced this issue Feb 15, 2019
@domenic @mustaqahmed
Clarify and tweak <embed> processing model
57e2107 
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 whatwg#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.
@guevara guevara mentioned this issue May 28, 2019
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
clarification Standard could be clearer topic: embed and object
Milestone
No milestone
Development

No branches or pull requests
3 participants
@qdot @domenic @annevk