1045215 - Disable plugins in prerendered documents

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect, P3)

Comment 1

[John Schoenick [:johns]]

nsDocShell::SetAllowPlugins is probably the simplest way to do this, but I don't see any explanation of how pre-rendering works in the bug. Is the pre-rendered page somehow un-frozen when it becomes live? We'll need a way to tell all <object> tags to wake up at that point, but if script is allowed to run it will cause bustage, as plugins are expected to be synchronously available.

Comment 2

[(no longer active)]

Oh, right.  I meant to post to dev-platform about the design that I have suggested for this, but I forgot...  Need-info-ing myself to remember to do this tomorrow.

Comment 3

[(no longer active)]

Oh, but to answer your question John, the prerendered document will be "unfrozen" by being replaced into a normal docshell using swapDocShells, so there will be a pagehide/pageshow event dispatched, and we can hook up notifications from there to tell the <object>s to wake themselves up.

I don't know what to do if script tries to access the plugins though.  :/  We do need to allow scripts to run.  Is there any way that we can detect errors as a result of script trying to access the plugin in Gecko?  If yes, then we can hook this up to the mechanism to kill the prerendered documents in case they do something that is unsafe in prerendering.

Comment 4

[John Schoenick [:johns]]

(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment #3)
> Oh, but to answer your question John, the prerendered document will be
> "unfrozen" by being replaced into a normal docshell using swapDocShells, so
> there will be a pagehide/pageshow event dispatched, and we can hook up
> notifications from there to tell the <object>s to wake themselves up.
> 
> I don't know what to do if script tries to access the plugins though.  :/ 
> We do need to allow scripts to run.  Is there any way that we can detect
> errors as a result of script trying to access the plugin in Gecko?  If yes,
> then we can hook this up to the mechanism to kill the prerendered documents
> in case they do something that is unsafe in prerendering.

We have a ScriptRequestedPlugin event that we fire if script tries to access a blocked/CTP plugin that could be adapted [1], but this turned out to happen very often -- many/most things that programmatically create a flash object touch a property on the object tag after it is configured, which requires the plugin being spawned.

More generally though, are we going to allow prerendered pages to request additional resources or send XHRs? It seems like there will be a large list of things outside of plugins that will need to trigger an abort of the pre-render. I wonder if there's a way we could run each javascript event in a sandbox, and if it tries to do something bad, shelve the event and freeze the page until it actually loads.

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

Comment 5

[(no longer active)]

(In reply to John Schoenick [:johns] from comment #4)
> (In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from
> comment #3)
> > Oh, but to answer your question John, the prerendered document will be
> > "unfrozen" by being replaced into a normal docshell using swapDocShells, so
> > there will be a pagehide/pageshow event dispatched, and we can hook up
> > notifications from there to tell the <object>s to wake themselves up.
> > 
> > I don't know what to do if script tries to access the plugins though.  :/ 
> > We do need to allow scripts to run.  Is there any way that we can detect
> > errors as a result of script trying to access the plugin in Gecko?  If yes,
> > then we can hook this up to the mechanism to kill the prerendered documents
> > in case they do something that is unsafe in prerendering.
> 
> We have a ScriptRequestedPlugin event that we fire if script tries to access
> a blocked/CTP plugin that could be adapted [1], but this turned out to
> happen very often -- many/most things that programmatically create a flash
> object touch a property on the object tag after it is configured, which
> requires the plugin being spawned.

I see, thanks!

> More generally though, are we going to allow prerendered pages to request
> additional resources or send XHRs?

Yes.

> It seems like there will be a large list
> of things outside of plugins that will need to trigger an abort of the
> pre-render.

Indeed!

> I wonder if there's a way we could run each javascript event in
> a sandbox, and if it tries to do something bad, shelve the event and freeze
> the page until it actually loads.

We have some plans although there is no magical sandbox for us to use.  It will be a lot of work to triage stuff and then we'd need to do lots of testing...

Comment 6

[BMO Automation]

Resolving as wont fix, plugin support deprecated in Firefox 85.