Null check RenderWidgetHost pointer from RWHVChildFrame on input events

Null check RenderWidgetHost pointer from RWHVChildFrame on input events

Crash reports associated with the --isolate-extensions trial show
that a RenderWidgetHostViewChildFrame can receive mouse events even
after Destroy has been called on it, resulting in a null pointer
dereference since the RenderWidgetHost pointer has been cleared.

This CL checks the pointer for null and discards the event if the
RWHVCF is currently awaiting deletion.

BUG=571092
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation

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

[kenrb, 2016-01-28 20:46:52]

Description was changed from

==========
Null check RenderWidgetHost pointer from RWHVChildFrame on input events

Crash reports associated with the --isolate-extensions trial show
that a RenderWidgetHostViewChildFrame can receive mouse events even
after Destroy has been called on it, resulting in a null pointer
dereference since the RenderWidgetHost pointer has been cleared.

This CL checks the pointer for null and discards the event if the
RWHVCF is currently awaiting deletion.

BUG=571092
==========

to

==========
Null check RenderWidgetHost pointer from RWHVChildFrame on input events

Crash reports associated with the --isolate-extensions trial show
that a RenderWidgetHostViewChildFrame can receive mouse events even
after Destroy has been called on it, resulting in a null pointer
dereference since the RenderWidgetHost pointer has been cleared.

This CL checks the pointer for null and discards the event if the
RWHVCF is currently awaiting deletion.

BUG=571092
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation
==========

[kenrb, 2016-01-28 20:49:59]

Description was changed from

==========
Null check RenderWidgetHost pointer from RWHVChildFrame on input events

Crash reports associated with the --isolate-extensions trial show
that a RenderWidgetHostViewChildFrame can receive mouse events even
after Destroy has been called on it, resulting in a null pointer
dereference since the RenderWidgetHost pointer has been cleared.

This CL checks the pointer for null and discards the event if the
RWHVCF is currently awaiting deletion.

BUG=571092
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation
==========

to

==========
Null check RenderWidgetHost pointer from RWHVChildFrame on input events

Crash reports associated with the --isolate-extensions trial show
that a RenderWidgetHostViewChildFrame can receive mouse events even
after Destroy has been called on it, resulting in a null pointer
dereference since the RenderWidgetHost pointer has been cleared.

This CL checks the pointer for null and discards the event if the
RWHVCF is currently awaiting deletion.

BUG=571092
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation
==========

[kenrb, 2016-01-28 20:49:59]

kenrb@chromium.org changed reviewers:
+ nick@chromium.org

[kenrb, 2016-01-28 20:51:24]

Nick: Would you mind giving this a quick review? I'm giving up (for now) on
understanding *why* input events can still route to a RWHVChildFrame after it
has had Destroy() called, but at least gracefully handling that it does.

[ncarter (slow), 2016-01-28 21:40:41]

OK as a stopgap lgtm

[kenrb, 2016-01-28 22:27:21]

The CQ bit was checked by kenrb@chromium.org

[commit-bot: I haz the power, 2016-01-28 22:28:43]

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

[commit-bot: I haz the power, 2016-01-29 00:09:43]

Description was changed from

==========
Null check RenderWidgetHost pointer from RWHVChildFrame on input events

Crash reports associated with the --isolate-extensions trial show
that a RenderWidgetHostViewChildFrame can receive mouse events even
after Destroy has been called on it, resulting in a null pointer
dereference since the RenderWidgetHost pointer has been cleared.

This CL checks the pointer for null and discards the event if the
RWHVCF is currently awaiting deletion.

BUG=571092
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation
==========

to

==========
Null check RenderWidgetHost pointer from RWHVChildFrame on input events

Crash reports associated with the --isolate-extensions trial show
that a RenderWidgetHostViewChildFrame can receive mouse events even
after Destroy has been called on it, resulting in a null pointer
dereference since the RenderWidgetHost pointer has been cleared.

This CL checks the pointer for null and discards the event if the
RWHVCF is currently awaiting deletion.

BUG=571092
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation
==========

[commit-bot: I haz the power, 2016-01-29 00:09:44]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-01-29 00:10:36]

Description was changed from

==========
Null check RenderWidgetHost pointer from RWHVChildFrame on input events

Crash reports associated with the --isolate-extensions trial show
that a RenderWidgetHostViewChildFrame can receive mouse events even
after Destroy has been called on it, resulting in a null pointer
dereference since the RenderWidgetHost pointer has been cleared.

This CL checks the pointer for null and discards the event if the
RWHVCF is currently awaiting deletion.

BUG=571092
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation
==========

to

==========
Null check RenderWidgetHost pointer from RWHVChildFrame on input events

Crash reports associated with the --isolate-extensions trial show
that a RenderWidgetHostViewChildFrame can receive mouse events even
after Destroy has been called on it, resulting in a null pointer
dereference since the RenderWidgetHost pointer has been cleared.

This CL checks the pointer for null and discards the event if the
RWHVCF is currently awaiting deletion.

BUG=571092
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation

Committed: https://crrev.com/b85b92b4639f690a9a523a910211d432dba568a2
Cr-Commit-Position: refs/heads/master@{#372211}
==========

[commit-bot: I haz the power, 2016-01-29 00:10:36]

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

[dcheng, 2016-01-29 05:20:11]

On 2016/01/28 at 21:40:41, nick wrote:
> OK as a stopgap lgtm

+site-isolation-reviews

Do we have a bug filed to followup and investigate what's going on here?

[kenrb, 2016-01-29 15:21:20]

On 2016/01/29 05:20:11, dcheng wrote:
> On 2016/01/28 at 21:40:41, nick wrote:
> > OK as a stopgap lgtm
> 
> +site-isolation-reviews
> 
> Do we have a bug filed to followup and investigate what's going on here?

We could reuse the original bug, or close that one when it is clear that the
crashes are resolved and file a new one.