From the GH issue

```
The particular path you're seeing is because HTMLDocument has an
ObjectTemplate that's marked as a cacheable template. The HTMLDocument
instance you're seeing is in the instantiations cache for that reason. That
cache is held on by the native context, which is held on by the
HTMLDocument constructor (which as "context" pointer points to the native
context). The constructor is installed on the __proto__ of another
HTMLDocument from the same native context. (I'm not sure why there are
multiple HTMLDocument instances in the same native context, this is out of
my expertise.) That second HTMLDocument is the rooted one.
```

Oilpan can only clean up documents that are not rooted anywhere by V8. If we cache them somehow (through templates) the GCs will not be able to clean up anything as the cache is rooting them.

Didn't have time to repro yet.

Indeed leaks. 

My first best guess would be that setting `src` does not create a new native context and that we thus just fill the fast_instantiations_cache which keeps alive all the older documents. The size of this cache is bound to 1KB, which means that we would leak until having that many entries.

When I replaced the following line
    frame.src = count % 0 ? url1 : url2;
with
    frame.src = count % 2 ? url1 : url2;
then, the issue doesn't reproduce.

Note that |count % 0| always evaluates to NaN, which evaluates to |false|, so the repro case is always loading |url2|.  My understanding is quite shallow, but I understand that, if the URL is the same except for the hash part, Blink treats it as "move in the current page" rather than "load a new page".  Maybe this is relevant?  (I'm not sure about anything, just off the top of my head.)

#4: I'd think we should be reusing the same ObjectTemplate, though. Stamping out new ObjectTemplate for each HTMLDocument doesn't sound right.

Assigning to yukishiino@ so that this has an owner.

yukishiino@, I'll take a look if you don't mind.

I left http://static.iamstef.net/iframe-leak-1.html running over night on Chrome 66 since that's the version where we have precise DOM retaining paths.

The iframe leak didn't reproduce for me.

There is a slow leak of Script objects retained by DevTools debugger. That one is working as intended because the debugger keeps strong handle to all created script objects.

yukishiino@, mlippautz@, since you were able to repro before, could you please try Chrome 66?

Deleted: Screen Shot 2018-02-21 at 10.04.33 AM.png 996 KB

	Screen Shot 2018-02-21 at 10.04.33 AM.png 996 KB View Download

The issue no longer reproduces with M66 (dev) nor ToT on my environment.

Thank you, yukishiino@, for confirming. Looks like it was fixed in the meantime.

Marking it as fixed.

I'll try to bisect and find out what was the fix when I get back to my desktop machine next week.

The NextAction date has arrived: 2018-02-26

My apologise for reopening this issue. I see a fix has supposedly landed in Chromium 66. Has this fix been backported to any other versions of Chromium?

This bug currently effects a large number of Electron users who are not able to upgrade Chromium versions until the Electron team does.

I don't think anything was backported, and there are no plans to do so either, as 66 is the current stable series and anything older than that is considered unsupported.

It should be possible to backport the commits to the Chromium version Electron currently uses, but you'd first need to find out which ones they are.