Crash by dragging a file to a new tab in certain circumstances
Reported by
jm.acun...@gmail.com,
Aug 30 2017
|
|||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36
Steps to reproduce the problem:
1- access to:
data:text/html,<script>function go() {var iframe = '<iframe src="http://feeds.feedburner.com/GoogleInbox"></iframe>';document.body.innerHTML = iframe;alert();go();};</script><input type="button" value="test" onclick="go()"/>
2- open new tab
3- drag any local file to the new tab without releasing
4- crash occurs
I can only reproduce it if the iframe source returns a windows authentication dialog (http://feeds.feedburner.com/GoogleInbox)
What is the expected behavior?
What went wrong?
The browser crashes.
Crash ID: crash/4225bbbbe4b943f7
Did this work before? N/A
Chrome version: 60.0.3112.113 Channel: stable
OS Version: 6.3
Flash Version:
,
Aug 30 2017
Crbug which is fixed and verified before: https://bugs.chromium.org/p/chromium/issues/detail?id=665250
,
Aug 31 2017
This is all kinds of fun. To be clear about the repro, it's 1) load the specified data: url 2) click the "test" button on the page 3) while the alert is up, click the new tab button (the original page will grab focus again) 4) drag a local file onto the newly-created, now-background tab On Windows, step 4 crashes. On the Mac, we crash on step 3.
,
Aug 31 2017
,
Aug 31 2017
Actually, on the Mac we DCHECK on step 3. Still...
,
Sep 7 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d1219ed17817d82eab0dda6da66ff0fb711d0fb8 commit d1219ed17817d82eab0dda6da66ff0fb711d0fb8 Author: Avi Drissman <avi@chromium.org> Date: Thu Sep 07 03:15:54 2017 Only show a dialog if the tab is visible. When initially showing a dialog, the tab is tested to see if it is visible. If not, the dialog is not shown, but is shown once the tab becomes visible (see WebContentsModalDialogManager::WasShown()). When showing the next dialog in the queue, the tab wasn't tested for visibility, which caused a problem when a dialog was dismissed while the tab was not visible. Now, if a dialog is dismissed while its tab isn't visible, the next dialog is not shown. It will be shown once the tab next becomes visible, as in the above case. BUG= 760507 TEST=as in bug Change-Id: If037c986c98d8d93de36556389d371dcda438078 Reviewed-on: https://chromium-review.googlesource.com/653800 Reviewed-by: Mike Wittman <wittman@chromium.org> Commit-Queue: Avi Drissman <avi@chromium.org> Cr-Commit-Position: refs/heads/master@{#500204} [modify] https://crrev.com/d1219ed17817d82eab0dda6da66ff0fb711d0fb8/components/web_modal/web_contents_modal_dialog_manager.cc
,
Sep 8 2017
OK. It turns out that the DCHECK was actually catching the issue that was crashing the Windows. If you test it now, you'll see that the original tab is doing alert after alert rather than crashing, which is the correct behavior. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by mmenke@chromium.org
, Aug 30 2017Components: -UI UI>Browser>TabStrip Blink>HTML>Dialog