Revert "Refactor sudden termination"

Revert "Refactor sudden termination"

This reverts commit df1975e5b02f1d53b35d7fceaa14c081a6097a03
(https://codereview.chromium.org/857213003). This caused an issue with the
flash video player stopping playing when going from fullscreen back to normal
on certain pages.

BUG=461530
TBR=nasko@chromium.org

Committed: https://crrev.com/c0a2786729dea4f6ce245008435e4ebd83d02496
Cr-Commit-Position: refs/heads/master@{#322017}

[clamy, 2015-03-16 15:47:23]

clamy@chromium.org changed reviewers:
+ creis@chromium.org, nasko@chromium.org

[clamy, 2015-03-16 15:47:23]

@creis, nasko: PTAL
Since I cannot reproduce the bug locally, I have no way to investigate precisely
why the other fix is working. Considering that the bug is a stable blocker, I
went with reverting the change instead.

[Charlie Reis, 2015-03-16 17:34:07]

Hmm, looks like it didn't apply cleanly-- the try jobs failed to compile.  Guess
other code has landed assuming your change is in place.

I agree that a revert is reasonable if we can't track down the regression the
original CL caused, so maybe this is just a matter of getting it to apply
cleanly.

That said, do you have any leads on how we might later track down the problem
and re-land this?  It sounded like you had a theory about how it was on or off
by default, and perhaps there's a way to confirm that locally even if you can't
repro the steps from the bug.

(I mention it because that may or may not be easier than getting this revert to
apply.  I didn't realize it would be problematic.)  :)

[clamy, 2015-03-17 17:34:54]

I think I might have been wrong on the not being on by default theory (reread
the code and this is not the case). Therefore, it seems that it's only the
DOMStorage callbacks that can cause the issue, since they would disable sudden
termination in the process, and so in all associated RenderViews. Hence I don't
think we can have the sudden termination of a frame not depend on the status of
the process. I guess it would be a problem if a frame got swapped out while in
the middle of trying to write to DOMStorage.

[clamy, 2015-03-24 14:03:05]

Considering the time frame, I'd like to go ahead and submit the revert of the
CL. I will try to reland it after doing the proper investigations about the
DOMStorage callbacks.

I fixed the compilation error: it was due to the original CL changing the return
type of WebContentsImpl::GetMainFrame to RenderFrameHostImpl. I left that in the
code rather than modifying the call sites of GetMainFrame to do the cast.

[Charlie Reis, 2015-03-24 17:02:18]

Thanks.  Rubber stamp LGTM for the revert.

Looking forward to getting the issue figured out so we can reland it!

[clamy, 2015-03-24 17:04:55]

Thanks! TBRing nasko@ for the change in frame_messages.h.

[clamy, 2015-03-24 17:05:02]

The CQ bit was checked by clamy@chromium.org

[commit-bot: I haz the power, 2015-03-24 17:05:20]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1014623002/20001

[commit-bot: I haz the power, 2015-03-24 17:09:12]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-03-24 17:10:09]

Patchset 2 (id:??) landed as
https://crrev.com/c0a2786729dea4f6ce245008435e4ebd83d02496
Cr-Commit-Position: refs/heads/master@{#322017}