[Bug 9221] still unclear definition of "plugin"

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9221


Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




--- Comment #1 from Ian 'Hixie' Hickson <ian@hixie.ch>  2010-04-01 02:25:49 ---
> I'm still confused about whether the code that displays a JPG is a 
> plugin or not. It seems to fall under the definition above.

It can. Historically, for example, PNG support in IE for a while matched this
definition. I believe SVG in Mozilla can match this definition (e.g. if used
from <embed>, IIRC).


> "Typically such content handlers are provided by third parties, though a 
> user agent can designate content handlers to be plugins."
> 
> I have a hard time understanding what the 2nd part of this sentence 
> means; can somebody help me with that?

A user agent (typically this would be a browser) can designate (that is,
appoint, state that it is the case that) content handlers (that is, code that
handles specific kinds of content) to be plugins (i.e. being selectable when
the user agent is searching for an applicable plugin for some content of a
relevant specific kind, and causing the content of that kind to be rendered in
a browsing context as part of a Document's rendering, but not actually
introducing a child browsing content nor having any corresponding Node objects
in the Document's DOM).


> Looking at
> 
> "...However, a PDF viewer application that launches separate from the 
> user agent (as opposed to using the same interface) is not a plugin by 
> this definition."
> 
> ...we might want to consider to coin a term for this; it might be needed 
> in other places ("helper application"?).

I don't think it's needed anywhere else, but yes, if it were, helper app is the
normal term for this.


> Going back to Bugzilla; Ian writes in 
> <http://www.w3.org/Bugs/Public/show_bug.cgi?id=8828#c5>:
> 
> > It's possible for a plugin to support JPG types, yes. More common is for
> > browsers to natively support SVG or PDF yet have that support fall into the
> > "plugin" definition. Really the only effect is whether <embed> can display the
> > content or not.
> 
> So this confirms that any code that displays a JPG falls under the 
> definition of "plugin".

Not any code, no. Typically a browser will not designate its JPEG handler as
being a plugin. You can tell if a browser has so designated its content handler
by trying to display a JPEG in <embed>.


> I fail to understand the comment about <embed>, unless it's mean to 
> apply to <object> as well.

<object> will is not limited to plugins. <embed> is. Assuming the browser has
any inline JPEG support at all, the <object> element will render JPEGs whether
or not its JPEG handler is designated a plugin.


> The whole thread was started because of "sandboxed" vs plugins. The 
> definition of <iframe> currently says:
> 
> "The sandboxed plugins browsing context flag
> 
>      This flag prevents content from instantiating plugins, whether 
> using the embed element, the object element, the applet element, or 
> through navigation of a nested browsing context."
> 
> Does that imply that a plugin that was invoked through <img>, <audio> or 
> <video> would be allowed to run?

The text above is non-normative (it doesn't have any conformance criteria), so
it doesn't imply anything. It's just giving a vague description of the intent
of the flag.

In any case, <img>, <audio>, and <video> can never invoke plugins as defined by
HTML.


EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the tracker issue; or you may create a tracker issue
yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: No change appears to have been requested.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 1 April 2010 02:25:51 UTC