This page has iframes embedded in resizable container <div>s. The iframes' CSS makes them take up all of their container.
Using CSS-powered resizing
These versions use the CSS resize property to allow resizing the outer <div>.
Cross-origin
This frame is likely to end up in a different process.
Same-origin
This frame will end up in the same process.
Using JS-powered resizing
These versions use JavaScript to perform the resizing. Grab the blue handle. Note the iframes have pointer-events: none on them to allow us to capture mousemove events, so their contents are not interactive.
Cross-origin
This frame is likely to end up in a different process.
Same-origin
This frame will end up in the same process.
Mitigation explorations
These versions also uses JS-powered resizing. They show how we can try to mitigate the problem by using custom background images in the outer page. Also, it makes the inner page extremely expensive to render by using 40,000 stacked gradients to draw the top bar.
If a browser implements a good "checkerboarding" algorithm, it could make "Cross-origin with no custom background" look "Cross-origin with a solid-color background", without the developer having to do anything special. (For Chromium, that's bug 1174279.) But it would be much harder to make "Cross-origin with no custom background" look like "Cross-origin with a custom background".
Same-origin (no custom background)
This should give a no-lag experience while resizing. (Well, the resizing will be slow, but the frame will not lag its container.)
Cross-origin with no custom background
Note how the header lags behind when resizing, and the pink background shows through.
Cross-origin with a solid-color background
Here, the <div> surrounding the frame has a white background, instead of pink.
Cross-origin with a custom background
Here, the <div> surrounding the frame has a background applied to match the iframe.