DescriptionStop using nested message loop for alert() and other JS dialogs
alert() needs to block on a single boolean result and is currently using
a nested loop to process async messages while waiting for a reply from
browser process. The nested loop adds a huge complexity to the subsystem as
it requires support for reentrancy and reordering in handling every message.
Especially, when ImeThread feature was enabled, it was causing a DCHECK
failure and a hang because some messages got unexpectedly reordered.
Instead of landing a workaround for ImeThread case, this removes nested
message loop use case for RenderFrameImpl.
Other changes here includes:
1) Fix ExtensionApiTest not to send async messages and wait for result
while alert dialog is showing up. This would hang otherwise.
2) Change UnloadController / FastUnloadController to check whether
beforeunload events have already been fired in the case of devtools.
We were firing beforeunload events twice when closing devtools
incorrectly even before this change, but closing process continued
because async messages were allowed. This fixes
DevToolsBeforeUnloadTest::TestUndockedDevToolsApplicationClose.
3) For 2), change Browser and BrowserTabStripModel to call non-static
member functions.
4) Fix UnloadTest by removing the two second wait limit. Sometimes it took
more than 2 seconds just to close the browser, but the test could close
the browser because async messages were allowed. Now the test fails if
before unload dialog shows up, so we prevent it by running an infinite
loop.
BUG=604675
Committed: https://crrev.com/6ed4d4373c5ce4743850df50f94b867240472033
Cr-Commit-Position: refs/heads/master@{#394883}
Patch Set 1 #Patch Set 2 : #
Total comments: 4
Patch Set 3 : removed DoNotNotifyWebKitOfModalLoop and fixed test #Patch Set 4 : use infinite loop instead of 10 secs #
Total comments: 2
Patch Set 5 : updated comment #
Total comments: 11
Patch Set 6 : updated comments and removed unused declaration #Messages
Total messages: 29 (9 generated)
|