1853936 - File Picker window is not closed after associated web content window is closed

Status: RESOLVED DUPLICATE of bug 1837008

(Core :: Widget: Win32, defect)

Description

[Jayateertha Guruprasad]

Attachment: ff.zip

Description - File Picker window is not closed even after associated web content window is closed.

Impact -

1. Parent process which initiated child process is responsible for management of lifecycle of child process which includes proper termination which other wise would lead to unintended resource usage(CPU/Memory) or zombie process.
2. Excessive memory/cpu resource usage than required due to improper process lifecycle management. (Affects availability triad in security point of view, this is more important when working in a resource restrictive environment)
3. There's a ongoing topic in whatwg which discusses about getting updates from file picker cancel event in the parent window, if this is implemented in future might again lead to unintended vulnerabilities/memory leaks as file picker will update to a inexistent tab in the call back.

Steps Of Reproduction -

1. Open parent.html, This will automatically open child.html in new tab (ensure open pop up is allowed).
2. child.html window has a file input, click on it file picker will open.
3. Now in the parent.html window, click on Close POP UP Button, which will close the child.html window, Notice that File Picker of child.html is still open.
4. Now Close the parent.html window, Notice that File Picker of child.html is still open even after whole firefox browser is closed (all tabs & windows).

parent.html -

<button onclick="openPop()">Open POP UP</button>
<button onclick="closePop()">Close POP UP</button>
<script>
w = window.open("child.html","","popup");
function openPop(){
w = window.open("child.html","","popup");
}
function closePop(){
w.close()
}
</script>

child.html -

<input type="file" id="file1"></input>

Comment 1

[Jayateertha Guruprasad]

Affected Version: 117.0.1 (64-bit) (Windows 11)

Comment 2

[Jayateertha Guruprasad]

Keeping the File Picker Window Open for sometime (may be 2-5 mins) after all the associated window & tabs are closed, causes crash. (This might be UAF or some memory issue, have already submitted a similar report to chromium team too)

Note: Chrome didn't crash as In chrome file picker is closed of browser(all tabs & windows) is closed.

Comment 3

[Andrew McCreight [:mccr8]]

What OS are you on? I can't reproduce this on MacOS because I am unable to interact with any browser windows while the file picker is open.

Could you please go to about:crashes and attach the link from https://crash-stats.mozilla.org/ for the crash? This will help us triage the bug. Thanks.

Comment 4

[Andrew McCreight [:mccr8]]

I'm changing the summary to be more specific. "Insecure" could mean a lot of things.

Comment 5

[Jayateertha Guruprasad]

(In reply to Andrew McCreight [:mccr8] from comment #4)

I'm changing the summary to be more specific. "Insecure" could mean a lot of things.

Here's the crash report url - https://crash-stats.mozilla.org/report/index/4122cf2b-463e-47f0-90df-d77960230919
I am using 117.0.1 (64-bit) (Windows 11)

Comment 6

[Andrew McCreight [:mccr8]]

Ray, Nika said you've been looking at file picker stuff. Does this sound like a familiar issue? Thanks.

Comment 7

[Andrew McCreight [:mccr8]]

This sounds like a Window widget issue, at most, and a shutdown hang is not a security issue. Having a random file picker hanging around doesn't seem like an issue either.

Comment 8

[Ray Kraesig [:rkraesig]]

The not-closing-on-window-closure bug is Bug 1837008, despite the different phrasing. I concur that it's not a security bug, even in the hypothetical case described in the reporter's #3. (That already has to be handled: the user could select a file in that state rather than cancelling.)

The "crash" if the file picker is left open in that state can be easily reproduced, as seen here; as the signature on both it and the user's provided crash report implies, this is a deliberate termination due to a detected shutdown hang, rather than a memory issue.