Two observations more:

- crash also occurs if you click the Cancel button
- the operation is correct if the window is closed from the blade

Do you have a crash id in chrome://crashes? That would help us triage this issue.

Crash ID: crash/eccc0d7500000000

Thank you fir the report, the crash id could not fetch any report could you please provide another one by the latest.
And if possible please provide the static html page with an input file type to triage from chrome TE side.

Confirmed.  It hangs, not crash.
No reproducible on macOS.

 Issue 654485  has been merged into this issue.

The hang appears also on the version 53.0.2785.143 m Windows 8/10

 Issue 759848  has been merged into this issue.

Hello guys, I see my ticket was mergen into this one. Have you been able to fix this bug? I see this ticket is from 11 months ago.

Thanks in advance

Hello,
Would really appreciate if someone can comment on this. This is causing chrome to crash in gmail, dropbox (all major file based softwares). I think this should be a decently big one for you.

Even if you can suggest how we can prevent crash (by trapping some event...) we would greatly appreciate it

Re #11-- Can you elaborate as to why this is a problem for you? The steps described (using a File Open dialog box to drag a file to a web page instead of selecting one and hitting Ok) are easily avoided and not necessary or common when using the sorts of services described. 

The issue happens even if you do not press Ok sometimes. It's sporadic. It seems like user won't do this but lot of our users are doing this and getting very upset. As I said it happens even if you drag and leave (not pressig ok).

Appreciate your thoughts,

 Issue 812697  has been merged into this issue.

 Issue 852807  has been merged into this issue.

 Issue 852807  gives us a good repro for this one.

Stability sheriff ping - robliao@, can you triage this and prioritize accordingly? It has been open for close to two years.

I just realized there's no analysis here from the previous investigation, so I'll loosely copy what I sent to brucedawson:

This bug a classic reason why it's very bad to join on terminating COM threads...

The issue is that the shell dialog thread needs to talk to an STA (and I strongly suspect this is the UI thread). The UI thread, in the meantime, is waiting for the shell dialog thread to terminate.

The fix here is to have the shell dialog stuff move to the Task Scheduler, making the thread join go away, and unblocking everyone.

Details:

0:046> kn200 [Requesting to shutdown the apartment and probably needs to tell a proxy on the UI thread we're going away.]
 # ChildEBP RetAddr  
00 1a9eee34 757ed3ee win32u!NtUserMsgWaitForMultipleObjectsEx+0xc
01 1a9eeea4 757aaf1d user32!RealMsgWaitForMultipleObjectsEx+0x7e
02 1a9eeecc 75be3fe6 user32!MsgWaitForMultipleObjectsEx+0x3d
03 1a9eef04 75be3e4c combase!CCliModalLoop::BlockFn+0xfd [onecore\com\combase\dcomrem\callctrl.cxx @ 2351] 
04 1a9eef48 75be3c38 combase!ModalLoop+0xb3 [onecore\com\combase\dcomrem\chancont.cxx @ 171] 
05 1a9eef64 75c0ac93 combase!ClassicSTAThreadDispatchCrossApartmentCall+0x48 [onecore\com\combase\dcomrem\chancont.cxx @ 326] 

0:000> kn10 [Hey, when is that shell dialog going away? Surely it doesn't need to talk to me, does it?]
 # ChildEBP RetAddr  
00 04bbf184 74d62329 ntdll!NtWaitForSingleObject+0xc
01 04bbf1f8 74d62282 KERNELBASE!WaitForSingleObjectEx+0x99
02 04bbf20c 6886ded7 KERNELBASE!WaitForSingleObject+0x12
03 04bbf234 6886e2fc chrome!base::PlatformThread::Join+0x67 [C:\b\c\b\win_clang\src\base\threading\platform_thread_win.cc @ 249] 
04 04bbf24c 6886e53b chrome!base::Thread::~Thread+0x2c [C:\b\c\b\win_clang\src\base\threading\thread.cc @ 64] 
05 04bbf258 6926134f chrome!base::Thread::~Thread+0xb [C:\b\c\b\win_clang\src\base\threading\thread.cc @ 63] 
06 04bbf274 68ea81bb chrome!ui::BaseShellDialogImpl::EndRun+0x51 [C:\b\c\b\win_clang\src\ui\shell_dialogs\base_shell_dialog_win.cc @ 53] 
07 04bbf290 68ea8372 chrome!`anonymous namespace'::SelectFileDialogImpl::FileNotSelected+0x29 [C:\b\c\b\win_clang\src\ui\shell_dialogs\select_file_dialog_win.cc @ 513] 

Taking off sheriff queue, since issue is understood, and has an owner.

Rob, presumably the key difference between joined-thread and TaskScheduler based impl will be the need to decouple the dialog from whoever called it, so that we don't crash if it out-lives whoever initiated it?

Re: #19. I suspect that's the case. There will need to be a handoff to the TaskScheduler thread for destruction which may make things fun if we have sequence/thread checkers on the original object.

Marking this for M70 when the team may have more bandwidth to fix this.

Issue 849259 has been merged into this issue.

Testcase 6211615532515328 failed to reproduce the crash. Please inspect the program output at https://clusterfuzz.com/testcase?key=6211615532515328.

 Issue 895166  has been merged into this issue.

Since pmonette@ is working on moving the File Dialog out of proc, that should effectively solve this issue (as long as the utility process migration also uses the task scheduler)

[Stability Sheriff] Should this bug be marked as blocking on the OOP File Dialog work in  Bug 884802 ?

That is marked as P3, perhaps the priority should be upgraded? The fix would address some user visible hangs - there are at least 8 duplicates of this bug that have been filed.

robliao@

This was possibly solved when I removed the use of base::Thread for dialogs in this CL? https://chromium-review.googlesource.com/c/chromium/src/+/1265158

Cool.  That patch landed in 71.0.3576.0.  Do any of the cases from this bug,  Bug 843040 , or  Bug 759848  reproduce in M71 beta (71.0.3578.44)? 

Can try to check after lunch.

 Issue 497928  has been merged into this issue.

 Issue 843040  has been merged into this issue.

[Stability Sheriff]  In Chrome 72.0.3608.0 , I tried the repro steps from:

 Bug 424538  (tinypng.com)
 Bug 759848  (w3schools.com)
 Bug 843040 ,  Bug 901404  (https://jsfiddle.net/hu5wv0zx/)
Bug 903722 (developer.mozilla.org)

by dragging and dropping a .jpg from the Win 10 file picker.  None of them hung the browser.  I'm tempted to call this fixed.

pmonette@, please verify independently.

The test described in
https://bugs.chromium.org/p/chromium/issues/detail?id=550455#c3
(dropzonejs.com) now succeeds in Chrome 72.0.3608.4 on Windows 10 Pro.
It failed in Chrome 70.0.3538.102 on Windows 10 Pro. I can't speak for
the other test cases, but for this one, thank you!