webview

so.... this was a fun journey into how to support iframed / video based content in electron. Let's play some memory allocation games shall we? What's 13 video tags + Google Chrome = If you guessed 110 megs to render the page, you'd be correct!.. let's follow along

When iframe's are invoked, basically an entire new DOM tree is built with all the same capabilities as the previous. Even if this is youtube it's still rendering a lot as far as memory that isn't needed. It's also a big ol' security hole for desktops (whaaaaa?? you say)

Chromium project knew this (both security and memory); I mean your running a system with full access to the desktop and then opening it to the web, you gotta secure it heavily and iframes are a massive gapping security / remote exploit dream for 0 days. So, I give you, "webview"

webview is a valid tag in Chromium based browsers (aka android and electron...ooohhh I see where we're going). webview was built to combat the security issue of iframes as well as the memory bloat. You can read more about them the approach here:

So, with some basic refactoring to our video-player tag to test if the environment is a secure environment (aka will hate iframes), we see if this works:

let test = document.createElement('webview');
if (typeof test.reload === 'function') {
  return true;
}
 

If "reload" is actually a function, we know the DOM created the real tag instead of just not knowing what the primitive was. Now, in our video-player we can test for being in a sandboxed environment. If it's sandboxed, we use <webview> instead of <iframe>. So what's the effect?

Beyond security, our electron app actually works. With iframes we see massive performance and stability problems when getting beyond 0 iframes on the page. It becomes almost unusable at 2 and stops en-mass at 3. Stack heap w/ 4 on the page went from 44 megs to 78 megs in 4frames!

Now after the webview refactoring we see the following:
With 20 video-player tags + more tags our app goes from 44 to 48.8 megs to deliver the page w/ all that media. That means what's being added via webview is marginal beyond what additional loads of custom elements might do!

So now, not only are we more secure but the CPU on your machine won't cook just bc iframes are on the page "in the app". It also means that it actually remains stable and makes our users way more happy then if the app would randomly break for seemingly no reason.

This is how I spent a good portion of the day (and @hey__MP too) trying to track down wtf we were seeing sporadic activity in our app. It also means that in order for users to be allowed to use iframes in #haxtheweb I'll have to do some additional magic which I'll go write now.