<input type="file"> is not kept alive during file picker, if it gets GC'd file selection has no affect

[Joseph Pecoraro]

A `<input type="file">` can get GC'd while the dialog is up if the element is not in the DOM.

When the Element is GC'd the FileChooser get's invalidated and the file selection gets dropped on the floor.

Should we try to guarantee the element is kept around while the picker is showing (at least not collected)? Note, Web Content has a workaround, but seems weird.

Test:
```
<button id="x">Click</button>
<script>
document.getElementById("x").addEventListener("click", () => {
    let inputElement = document.createElement("input");
    inputElement.type = "file";
    inputElement.multiple = true;
    inputElement.addEventListener("change", (event) => {
        alert('change');
    });
    inputElement.click();
});
</script>
```

Steps to reproduce:
1. Inspect test page
2. Click the button to show the File picker
3. While the file picker is showing trigger a Garbage Collection in Inspector's Console
4. Complete the file picker dialog with a file
  => Alert doesn't happen

Notes:
• I was able to reproduce the issue in Chrome once. Unable to try Firefox.

[Joseph Pecoraro]

Worked around this in Web Inspector: Bug 201289

But I wonder if this could affect a real page.

[Ryosuke Niwa]

This is a weird one. Technically, JS no longer has access to the file element because it had lost access to all its references (it's not a part of the document). But perhaps there is an expectation that the event will fire when the user dismisses the dialog or picks a file.

The way to fix this problem is to deploy GCReachableRef<HTMLInputElement> I added.

[Alexey Proskuryakov]

It’s also similar to media elements and Fetch, whose wrappers stay alive in the expectation of callback making them visible again.

[Ryosuke Niwa]

(In reply to Alexey Proskuryakov from comment #3)
> It’s also similar to media elements and Fetch, whose wrappers stay alive in
> the expectation of callback making them visible again.

Yeah, in that sense, perhaps HTMLInputElement should be an ActiveDOMObject with a pending activity whenever there is a dialog popped up.

[Chris Dumez]

(In reply to Ryosuke Niwa from comment #4)
> (In reply to Alexey Proskuryakov from comment #3)
> > It’s also similar to media elements and Fetch, whose wrappers stay alive in
> > the expectation of callback making them visible again.
> 
> Yeah, in that sense, perhaps HTMLInputElement should be an ActiveDOMObject
> with a pending activity whenever there is a dialog popped up.

That sounds about right.