Prevent reentrancy of WebFrameClient::didClearWindowObject.

Prevent reentrancy of WebFrameClient::didClearWindowObject.

When accessing window during didClearWindowObject, it's being dispatched again.
This happens quite often: in WebUI bindings, dom automation, DevTools, etc.

BUG=none

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=196398

[dgozman, 2015-06-01 15:24:02]

dgozman@chromium.org changed reviewers:
+ japhet@chromium.org, tommycli@chromium.org

[dgozman, 2015-06-01 15:24:02]

Hi,

Could you please take a look?

I've encountered the problem today, and found pretty similar patch at
https://codereview.chromium.org/1161983005. 
There are two calls to dispatchDidClearWindowObjectInMainWorld though, and one
was missing a check.

Thanks,
Dmitry

[tommycli, 2015-06-01 16:50:46]

lgtm. The patch looks fine to me, but nate is the ultimate owner.

Nate mentioned that we might just be fixing the symptom (reentrant calls) rather
than the root cause (why would the window object be cleared twice anyways?
wouldn't it only need to be done once?)

[dgozman, 2015-06-02 19:28:03]

On 2015/06/01 16:50:46, tommycli wrote:
> lgtm. The patch looks fine to me, but nate is the ultimate owner.
> 
> Nate mentioned that we might just be fixing the symptom (reentrant calls)
rather
> than the root cause (why would the window object be cleared twice anyways?
> wouldn't it only need to be done once?)

I don't really know. We need a FrameLoader expert to judge about this.

[Nate Chapin, 2015-06-02 21:29:28]

On 2015/06/02 19:28:03, dgozman wrote:
> On 2015/06/01 16:50:46, tommycli wrote:
> > lgtm. The patch looks fine to me, but nate is the ultimate owner.
> > 
> > Nate mentioned that we might just be fixing the symptom (reentrant calls)
> rather
> > than the root cause (why would the window object be cleared twice anyways?
> > wouldn't it only need to be done once?)
> 
> I don't really know. We need a FrameLoader expert to judge about this.

I'm guessing the FIXME in ScriptController::windowProxy() is the root cause. The
only way we reenter is that windowProxy() doesn't properly initialize the
WindowProxy, I think. LGTM on this, I guess.

[dgozman, 2015-06-03 05:04:20]

The CQ bit was checked by dgozman@chromium.org

[commit-bot: I haz the power, 2015-06-03 05:05:07]

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

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

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-06-03 09:17:04]

Try jobs failed on following builders:
  android_blink_compile_dbg on tryserver.blink (JOB_FAILED,
http://build.chromium.org/p/tryserver.blink/builders/android_blink_compile_db...)

[dgozman, 2015-06-03 11:34:25]

The CQ bit was checked by dgozman@chromium.org

[dgozman, 2015-06-03 11:34:25]

The patchset sent to the CQ was uploaded after l-g-t-m from
tommycli@chromium.org, japhet@chromium.org
Link to the patchset: https://codereview.chromium.org/1166493003/#ps10001
(title: "Fxied android compile")

[commit-bot: I haz the power, 2015-06-03 11:34:43]

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

[commit-bot: I haz the power, 2015-06-03 13:19:10]

Committed patchset #2 (id:10001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=196398