Removing plugins?

[domenic]

With Flash deprecation, it might be the case that browsers no longer implement plugins, and as such we could remove some of the spec complexity around them.

Note, however, that we do need to keep enough to allow rendering of PDFs, and to allow rendering of HTML pages (and other supported content types) in embed and object. So it's not like we can completely gut the embed and object sections.

And, it looks like at the time of #3958, Chrome treated PDFs as plugins. So maybe we can't remove much.

Anyway, some candidates for removal:

• Page load processing model for plugin documents, under the assumption that PDFs count as inline content that doesn't have a DOM (TODO test if that assumption holds; the above indicates it might not in Chrome)
• Sandboxing infrastructure for plugins, but see Interop: pdf might or might not render in a sandboxed iframe (depending on a browser) #3958 for PDF-related concerns
• Description of plugins
• NavigatorPlugins and friends, but see Consider a standardized way to detect PDF in HTML? #3462; PDF support might end up living here in existing browsers.
• embed and especially object could likely be simplified to be more like iframe.
• The param element might be able to be totally neutered and moved to the obsolete section.

The param simplification likely holds even if PDF ends up staying around as a plugin. (And in turn we can close #387.)

[annevk]

If we can remove https://html.spec.whatwg.org/#concept-embed-type that would be nice. Hopefully browsers do not look for .pdf.

[annevk]

The way Chrome and Firefox support PDF is as the result of a navigation, so plugin documents continue to exist, but I'm not sure they would be different from inline content that doesn't have a DOM as the result is basically a document with an opaque origin.

A question that came up in annevk/orb#5 is whether we can make these always create nested browsing contexts. I suspect that won't work due to images, but it might be worth investigating more. (See also w3c/webappsec-fetch-metadata#37 and w3c/webappsec-fetch-metadata#45.) whatwg/fetch#948 suggests this might be possible now plugins are removed, but we may need to keep some quirks. Seems very much worth investigating.

cc @anforowicz @arturjanc @mikewest

[annevk]

For navigator.plugins and navigator.mimeTypes I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1164635 and https://bugs.webkit.org/show_bug.cgi?id=220495.

[domenic]

It looks like @mfreed7 is interested in having Chrome follow Firefox and return empty for navigator.plugins and navigator.mimeTypes, hooray!

@annevk, can you give more details on what Firefox does? For example, I could imagine:

1. Totally removing PluginArray, MimeTypeArray, Plugin, and MimeType, and having navigator.plugins and navigator.mimeTypes return (frozen?) normal arrays.
2. Not removing any interfaces, and just having the lists always be zero-length, and navigator.plugins.refresh() always a no-op

... or something in between

I suspect (2) is going to be easiest, but is that what Firefox did? A spec PR would be great, where we can hash out the details.

(Also, I guess navigator.javaEnabled() always returns false now?)

[mfreed7]

😄

For at least a while (weeks? a milestone or two?) my plan is to just do #2. That also appears to be what Firefox has done, at least in effect. And in Chromium, FYI, javaEnabled() has been false since M45.

I'd be happy to do more (i.e. #1), but I suspect that would cause major compat issues. Navigator.plugins is used on 60% of pageloads today. And I would guess those numbers will stay high even after the APIs start returning [].

[domenic]

On the compat front, I suspect that removing PluginArray and MimeTypeArray would be hard, because of the extra methods (refresh(), item(), and namedItem()) which wouldn't be present on normal arrays.

But removing Plugin and MimeType might be easier, since if navigator.plugins and navigator.mimeTypes return [], then the only way to detect their existence is by checking for window.Plugin and window.MimeType, which is pretty pointless (and so, I would suspect, unlikely).

Going with just (2) for now makes a lot of sense to me; you're already taking on a nice chunk of work!

[mfreed7]

Good point about Plugin and MimeType. Perhaps while I'm emptying the arrays, I'll also add use counters for the Plugin and MimeType constructors. Then we can see how often people construct those directly.