[webkit-dev] Page Cache and Plugins

[Brady Eidson]

On May 5, 2011, at 00:25 , Basavaraj S.S wrote:

> Hi,
> 
> The Scenario :
> 
> For trial , Introduced Page cache functionality which was disabled on our custom browser on Symbian port.
> Pages were cached as expected and the Browser stability was decent.
> 
> To take the a step further, Unlike in WebKit, I also enabled the Pages/Frames to be cached which had plugins in it bycommenting out the line 
> 
>  && !frame->loader()->containsPlugins() in the function bool PageCache::canCachePageContainingThisFrame(Frame* frame).
> 
> The reason stated for not caching pages with plugins is that "There are no means to pause/resume a Netscape plug-in"

That's because there are no means to pause/resume a Netscape plug-in.

> But I could control plugins in my custom browser by Pausing them and Hiding their window when the page gets hidden when pushed to page cache and vice versa operation when resumed/restored.

Which plug-ins were you testing with?  And how did you "pause and hide their window"?

Note that "pausing a youtube video" or "pausing a flash game" do not mean you've actually paused the Netscape plug-in.  It simply means that you've given the Netscape plug-in a user command to stop playing video or to pause your Flash game.

There is still 3rd party native code executing, doing whatever it wants on your system.  That's the crux of the problem - once WebKit has loaded 3rd party native code either into its own process space or into a separate plug-in process, that code is happily allowed to continue doing whatever it wants until it is unloaded.

> This too worked well. Videos and other content were paused and resumed , Hid and displayed when required and the pages with plugins were cached successfully.

Even while the page was cached, and you suggest the plug-in was "paused", it was actually still a bundle of 3rd party native code that is allowed to do whatever it wants.  

> The Problem :
> 
> The problem started to occur when I started testing.
> Every time around 100 pages were loaded successfully but after that I saw random crashes at different places, mainly in void CachedFrame::clear() and FrameView destructor
> RAM was sufficiently free when crashes used to happen.

Not surprising - there's plenty of reasons why having 3rd party native code executing on behalf of a cached web page is a terrible idea.  Privacy, security, system performance, battery life, having audio play in the background from a mysterious source - those are only some of the reasons.

Other reasons include the fact that Netscape plug-ins can get references to DOM objects, and if they try to do anything to these "page cached" DOM objects, crashes can occur.

Also, if the page cached DOM objects are cleared without regards to the 3rd party native code that has a reference to them, crashes can occur.

> The Question :
> 
> So my question to the list is that " Is there or are there any other reason/s for not caching the frames with Plugins, apart from the reason mentioned  There are no means to pause/resume a Netscape plug-in ?"

The laundry list of bad things that I list above are all caused by the fact that *there are no means to pause/resume a Netscape plug-in*

~Brady


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110505/3be2deb9/attachment.html>