This algorithm has another bug, too: we shouldn't be blowing away the browsing context if the document goes into the session history (stops being fully active).

Maybe the solution here is to move the plugin unloading to step 1, add a step 2 that discards browsing contexts, and then remove anything to do with being fully active from this algorithm. Does that work?

So on navigation, plugins should be unloaded, but browsing context should not be destroyed?

Should probably also have a look at <embed>.

Yeah, <embed> is wrong too.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2940

For <embed>, looks like removing src="" doesn't remove the browsing context, but removing the element from the Document does.

Sounds like both elements should move to a similar model.

This model should probably be:
 - a set of conditions that are minimally required for the element to keep a 
   plugin/browsing context once it has one
 - a set of conditions that are minimally required for the element to gain a
   plugin/browsing context when it doesn't have one

Does that seem reasonable?

Yes, it does.  You may want to talk to John Schoenick (johns at mozilla.com) for some details, since he has been most actively involved in this part of the Gecko code (e.g. making plug-ins work even when display:none in some cases).

johns: Can you think of anything in particular I should be aware of here?

(In reply to Ian 'Hixie' Hickson from comment #5)
> johns: Can you think of anything in particular I should be aware of here?

A lot of our behavior in gecko was very questionably-intentional prior to rewriting a lot of the <object> tag binding. Now, a lot of it is explicit preceded by sad comments about legacy behavior. I have changed a handful of these to be more sane recently without encountering any significant fallout, such as delaying plugin unload to stable state in most situations.

As far as I can tell, the current situation in gecko is:

Browsing contexts: We unconditionally destroy the browsing context when unbound from tree (except possibly in the case of SVG documents being treated as an image type?) but have a comment noting we shouldn't be [1]. We don't destroy the browsing context when going inactive.

Plugins, whenever we: (1) go inactive (2) unbind from tree or (3) become un-rendered, we queue a on-stable-state event to unload the plugin, unless that condition resolves itself before the stable state (to accommodate re-parenting plugins without stopping them, for instance).

As a special case, we unload plugins/everything-else synchronously if a new load begins while in an active document. This is largely because of the pain of keeping the previous content around until stable state while trying to do a synchronous plugin load.

Speaking of, our most-fun behavior to maintain is synchronous plugin spawning, which, unfortunately, does have users as of the last time we tried to break it: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2959

Almost all of the behaviors above have changed slightly to be more consistent in the last year or two. This is very old, often poorly aged, code. I have fixed numerous oddities without finding any bustage, so I think we should be careful about adding nonsense behaviors to the spec unless there are known compat issues to removing them.

For instance, looking at the gecko code, removeAttribute('src') looks entirely like an oversight with a split class. In fact, I filed a bug [2] to fix it when refactoring some of this code. Knowing that it is apparently replicated into other UAs makes me sad.

[1] http://dxr.mozilla.org/mozilla-central/source/content/base/src/nsObjectLoadingContent.cpp#705

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=767631

Proposal for <embed>:

 - a set of conditions that are minimally required for the element to keep a 
   plugin/browsing context once it has one:

    - the element is in a Document
    - the element has either a src attribute or a type attribute or both
    - the element's src attribute is either absent or its value is not
      the empty string.
    - the element does not have a media element ancestor
    - the element does not have an ancestor object element that is not showing
      its fallback content
    - the element is being rendered (essentially this means not display:none)

   timing: if the conditions stop being met, then queue a microtask; if the
   conditions are still not met, do it then.

 - a set of conditions that are minimally required for the element to gain a
   plugin/browsing context when it doesn't have one:

    - the element matches the conditions listed above
    - the element's Document is fully active.

 - a set of triggers that cause things to be loaded:

    - the element's src attribute is set, removed, or changed
    - the element's type attribute is set, removed, or changed
    - the element's ancestor chain changes
    - the element has an <object> ancestor that starts showing its fallback
      content
    - the element starts being rendered

   when these triggers occur to pass, synchronously run the current steps to
   pick a plugin/browsing context/image/whatever. If it's just going to be based
   on the type, and we want to spawn a plugin, spawn the plugin synchronously; 
   otherwise, queue a microtask to do the rest of the work. In either case, this
   only happens if the first set of conditions described above are still met.

How does that look? Does it match implementations? If this looks sane, I'll see if the same model works for <object>.

johns mentions that we need to make sure that e.src=e.src forces a reload, but that generally when a load happens and we already have the same plugin loaded, we should do nothing.

(Presumably we can get away with not making e.setAttribute('src', e.src) reload?)

johns also mentioned that we should special-case Java to not fetch URLs if we think we need to run the Java plugin.

Specifically, in gecko:
- If the type is java, we ignore any src attr. Java doesn't expect us to open any initial stream for it, and doesn't usually use this attr for embed.
- Similarly, if we don't know the type and open a channel, and it returns a java type, the load fails.
- embed.src = embed.src *or* setAttribute(src, embed.src) would trigger a force-reload (any time SetAttr(src) occurs, aForceLoad is true). Because we don't unload plugins until stable state, just reparenting or hiding/unhiding a plugin doesn't restart it, so I believe this is used by web content to force the plugin to reload. I'm not sure if other UAs replicate this.

I don't know that working on cleaning up the various plugin related algorithms is going to be worth it. We trying to deprecate plugins so the value here is somewhat short-term, and my experience has been so far that any changes to any plugin stuff tend to cause more breakage than we are comfortable with, so the risks here are high.

Add to that that a lot of plugins are browser specific (especially these days when Firefox/Chrome/IE all have separate plugin APIs), which means that browsers can't necessarily align.

That said, I'm happy to defer to John here.

This isn't just plugins, it's also nested browsing contexts. The plugins are just in for the ride, really.

Having e.setAttribute('src', e.src) cause a reload seems very odd, since that really is a no-op. Is there compat need for that?

(In reply to Ian 'Hixie' Hickson from comment #12)
> This isn't just plugins, it's also nested browsing contexts. The plugins are
> just in for the ride, really.
> 
> Having e.setAttribute('src', e.src) cause a reload seems very odd, since
> that really is a no-op. Is there compat need for that?

From the way Gecko hooks/forces a reload here I think this is just along for the ride. I would guess that this is not super common for sites trying to reload a plugin, but to be sure we'd either need telemetry to watch for it in the wild or to try breaking it.

Further discussion suggests that maybe the src = src thing is a Gecko quirk. I'll have to test other browsers further.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3166 suggests that Chrome and Safari also do this, so I guess we have to spec it.

Next step here is for me to start from comment 7 and make a new game plan looking at the comments since then. I agree with sicking that this is somewhat low-priority effort... do we really think we can kill plugins completely? If so, maybe it's not worth doing this at all...

Our current plan of record on whatwg/html is to wait for Flash to be removed from browsers, so that object and embed become simpler and more similar to iframe, and then simplify and revamp their specifications. Embed has already gotten a bit better.

As such, I'll close this for now pending that work.