[Extensions Bindings] Introduce a supportsLazyListeners property

[Extensions Bindings] Introduce a supportsLazyListeners property

Right now, we determine whether to store the record of a lazy listener
in the extension prefs based only on the type of context - if the
context registering the listener is a lazy context (like an event page),
then we store a lazy listener in extension prefs.

This is incorrect for webview events.  Webview events are exposed on a
<webview> DOM object, but are implemented behind-the-scenes as
extension events (including the listener bookkeeping). However, having a
lazy listener for a webview event doesn't make sense:
- the only time a listener would be considered lazy is when the listener
  was added in a lazy context
- a lazy listener will only be used to wake up an inactive context
- webview events are tied to a specific webview
Thus, a lazy listener would only be used for a webview which has since
been torn down.

With this in mind, we can avoid registering any lazy listeners for
webview-related events. Introduce the key supportsLazyListeners into the
JSON schema and add it for webview events. When this key is present,
events don't register lazy listeners.

Wire this up for both native and JS-based bindings, and add unit tests
for the bindings and an end-to-end test to ensure that webview event
listeners will never be registered as lazy listeners.

A followup will add logic to clean up current prefs to remove traces of
the listeners.

BUG=736381
Review-Url: https://codereview.chromium.org/2973903002
Cr-Commit-Position: refs/heads/master@{#487991}
Committed: https://chromium.googlesource.com/chromium/src/+/91f0c8a3cc9d78c32e914b74c920c26ccd748968

[Devlin, 2017-07-06 23:00:40]

The CQ bit was checked by rdevlin.cronin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-07-06 23:00:48]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-07-06 23:12:49]

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

[commit-bot: I haz the power, 2017-07-06 23:12:50]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[Devlin, 2017-07-07 00:49:32]

The CQ bit was checked by rdevlin.cronin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-07-07 00:49:52]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-07-07 02:05:41]

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

[commit-bot: I haz the power, 2017-07-07 02:05:42]

Dry run: This issue passed the CQ dry run.

[Devlin, 2017-07-07 20:48:48]

The CQ bit was checked by rdevlin.cronin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-07-07 20:49:05]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-07-07 23:11:01]

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

[commit-bot: I haz the power, 2017-07-07 23:11:03]

Dry run: This issue passed the CQ dry run.

[Devlin, 2017-07-08 02:29:19]

Description was changed from

==========
webview lazy events
BUG=
==========

to

==========
[Extensions Bindings] Introduce a supportsLazyListeners property

Right now, we determine whether to store the record of a lazy listener
in the extension prefs based only on the type of context - if the
context registering the listener is a lazy context (like an event page),
then we store a lazy listener in extension prefs.

This is incorrect for webview events.  Webview events are exposed on a
<webview> DOM object, but are implemented behind-the-scenes as
extension events (including the listener bookkeeping). However, having a
lazy listener for a webview event doesn't make sense:
- the only time a listener would be considered lazy is when the listener
  was added in a lazy context
- a lazy listener will only be used to wake up an inactive context
- webview events are tied to a specific webview
Thus, a lazy listener would only be used for a webview which has since
been torn down.

With this in mind, we can avoid registering any lazy listeners for
webview-related events. Introduce the key supportsLazyListeners into the
JSON schema and add it for webview events. When this key is present,
events don't register lazy listeners.

Wire this up for both native and JS-based bindings, and add unit tests
for the bindings and an end-to-end test to ensure that webview event
listeners will never be registered as lazy listeners.

A followup will add logic to clean up current prefs to remove traces of
the listeners.

BUG=736381
==========

[Devlin, 2017-07-08 02:29:47]

rdevlin.cronin@chromium.org changed reviewers:
+ jbroman@chromium.org, lazyboy@chromium.org

[Devlin, 2017-07-08 02:29:47]

A significantly less-fun one. :(

[jbroman, 2017-07-10 15:33:02]

This lgtm, but I don't understand <webview> well enough to review that aspect of
it.

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/bin...
File extensions/renderer/bindings/api_binding.cc (right):

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/bin...
extensions/renderer/bindings/api_binding.cc:323: bool
temp_supports_lazy_listeners = false;
nit: Why is it so bad that we have to prevent "supportsLazyListeners: true" from
being specified that we force it to false (which is neither default nor what was
specified) in that case? It seems simpler to do:

if (options->GetBoolean("supportsLazyListeners", &supports_lazy_listeners)) {
  DCHECK(!supports_lazy_listeners)
      << "Don't specify supportsLazyListeners: true; it's the default.";
}

[lazyboy, 2017-07-14 00:04:43]

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/bin...
File extensions/renderer/bindings/api_binding.cc (right):

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/bin...
extensions/renderer/bindings/api_binding.cc:323: bool
temp_supports_lazy_listeners = false;
On 2017/07/10 15:33:02, jbroman wrote:
> nit: Why is it so bad that we have to prevent "supportsLazyListeners: true"
from
> being specified that we force it to false (which is neither default nor what
was
> specified) in that case?
I like it this way though: API schema owners need not worry about lazy listeners
and extension system takes care of the default: listeners from lazy context
would become lazy automatically. The slight deviation is only for webview and we
should not expect usages of this outside of webview events.

 It seems simpler to do:
> 
> if (options->GetBoolean("supportsLazyListeners", &supports_lazy_listeners)) {
>   DCHECK(!supports_lazy_listeners)
>       << "Don't specify supportsLazyListeners: true; it's the default.";
> }

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/bin...
File extensions/renderer/bindings/api_event_handler.h (right):

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/bin...
extensions/renderer/bindings/api_event_handler.h:30: // The callback to be
called when event listeners change. |was_manual|
Update documentation

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/res...
File extensions/renderer/resources/app_window_custom_bindings.js (right):

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/res...
extensions/renderer/resources/app_window_custom_bindings.js:26: var
supportsLazyListeners = false;
Shouldn't this be true?

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/res...
File extensions/renderer/resources/context_menus_handlers.js (right):

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/res...
extensions/renderer/resources/context_menus_handlers.js:21: var supportsFilters
= false;
Pull this out after line 19 and use it for eventOpts below too?

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/res...
extensions/renderer/resources/context_menus_handlers.js:29: { __proto__: null,
supportsLazyListeners: supportsLazyListeners };
I don't remember style guide put space after {, is this clang format? Does it
work for JS?

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/res...
extensions/renderer/resources/context_menus_handlers.js:30: return new
jsEvent(name);
Should we not use eventOpts here?

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/res...
File extensions/renderer/resources/guest_view/web_view/web_view_events.js
(right):

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/res...
extensions/renderer/resources/guest_view/web_view/web_view_events.js:44: return
new jsEvent(name, schema, options);
Can we DCHECK options.supportsLazyEvents == false?

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/res...
File extensions/renderer/resources/messaging.js (right):

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/res...
extensions/renderer/resources/messaging.js:29: var supportsLazyListeners =
false;
Do we need true here?

[lazyboy, 2017-07-14 00:08:40]

Also /cc James: Can you or someone from current webview team check the CL
description? We will make webview events never be lazy, this would only impact
<webview>s from app background pages (and not from app page). Hangouts have at
least one such <webview> AFAIK...

[wjmaclean, 2017-07-14 13:34:20]

On 2017/07/14 00:08:40, lazyboy wrote:
> Also /cc James: Can you or someone from current webview team check the CL
> description? We will make webview events never be lazy, this would only impact
> <webview>s from app background pages (and not from app page). Hangouts have at
> least one such <webview> AFAIK...

T

[wjmaclean, 2017-07-14 13:34:21]

On 2017/07/14 00:08:40, lazyboy wrote:
> Also /cc James: Can you or someone from current webview team check the CL
> description? We will make webview events never be lazy, this would only impact
> <webview>s from app background pages (and not from app page). Hangouts have at
> least one such <webview> AFAIK...

T

[wjmaclean, 2017-07-14 13:34:23]

On 2017/07/14 00:08:40, lazyboy wrote:
> Also /cc James: Can you or someone from current webview team check the CL
> description? We will make webview events never be lazy, this would only impact
> <webview>s from app background pages (and not from app page). Hangouts have at
> least one such <webview> AFAIK...

T

[wjmaclean, 2017-07-14 13:34:24]

On 2017/07/14 00:08:40, lazyboy wrote:
> Also /cc James: Can you or someone from current webview team check the CL
> description? We will make webview events never be lazy, this would only impact
> <webview>s from app background pages (and not from app page). Hangouts have at
> least one such <webview> AFAIK...

T

[wjmaclean, 2017-07-14 13:35:09]

On 2017/07/14 13:34:24, wjmaclean wrote:
> On 2017/07/14 00:08:40, lazyboy wrote:
> > Also /cc James: Can you or someone from current webview team check the CL
> > description? We will make webview events never be lazy, this would only
impact
> > <webview>s from app background pages (and not from app page). Hangouts have
at
> > least one such <webview> AFAIK...
> 
> T

The description looks fine to me. Thanks for the updates, and for adding the
test!

[Devlin, 2017-07-14 15:37:34]

The CQ bit was checked by rdevlin.cronin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-07-14 15:37:41]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Devlin, 2017-07-14 15:37:55]

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/bin...
File extensions/renderer/bindings/api_binding.cc (right):

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/bin...
extensions/renderer/bindings/api_binding.cc:323: bool
temp_supports_lazy_listeners = false;
On 2017/07/14 00:04:42, lazyboy wrote:
> On 2017/07/10 15:33:02, jbroman wrote:
> > nit: Why is it so bad that we have to prevent "supportsLazyListeners: true"
> from
> > being specified that we force it to false (which is neither default nor what
> was
> > specified) in that case?
> I like it this way though: API schema owners need not worry about lazy
listeners
> and extension system takes care of the default: listeners from lazy context
> would become lazy automatically. The slight deviation is only for webview and
we
> should not expect usages of this outside of webview events.
> 
>  It seems simpler to do:
> > 
> > if (options->GetBoolean("supportsLazyListeners", &supports_lazy_listeners))
{
> >   DCHECK(!supports_lazy_listeners)
> >       << "Don't specify supportsLazyListeners: true; it's the default.";
> > }
> 

I think jbroman@ was just saying that it seems excessive that we have a temp
variable here to guard against supports_lazy_listeners ever, ever being
specified as true (as opposed to *still* DCHECKing, but taking out the extra
temp variable).  I think it's a fair point - specifying true isn't the end of
the world, so as long as we still DCHECK (hopefully folks test! :P), it should
be fine.

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/bin...
File extensions/renderer/bindings/api_event_handler.h (right):

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/bin...
extensions/renderer/bindings/api_event_handler.h:30: // The callback to be
called when event listeners change. |was_manual|
On 2017/07/14 00:04:42, lazyboy wrote:
> Update documentation

Done.

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/res...
File extensions/renderer/resources/app_window_custom_bindings.js (right):

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/res...
extensions/renderer/resources/app_window_custom_bindings.js:26: var
supportsLazyListeners = false;
On 2017/07/14 00:04:42, lazyboy wrote:
> Shouldn't this be true?

Nope - anonymous events should never support lazy listeners - it wouldn't make
sense.  They have no name, and so we'd have no way of identifying a listener (or
an event instance) for them.  In JS, this is handled here:
https://chromium.googlesource.com/chromium/src/+/52a9ace924868ad72ad5e28fc05d...

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/res...
File extensions/renderer/resources/context_menus_handlers.js (right):

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/res...
extensions/renderer/resources/context_menus_handlers.js:21: var supportsFilters
= false;
On 2017/07/14 00:04:42, lazyboy wrote:
> Pull this out after line 19 and use it for eventOpts below too?

Wasn't like this previously because supportsFilters is false by default in JS. 
But, doesn't hurt to put it in, so done.

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/res...
extensions/renderer/resources/context_menus_handlers.js:29: { __proto__: null,
supportsLazyListeners: supportsLazyListeners };
On 2017/07/14 00:04:42, lazyboy wrote:
> I don't remember style guide put space after {, is this clang format? Does it
> work for JS?

I think clang-format doesn't (though JS support for that is still pretty
experimental).  But also our resources files *definitely* don't follow clang
format. :) (though they perhaps should!)  But, in either case, adding in
supportsFilters makes this moot.

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/res...
extensions/renderer/resources/context_menus_handlers.js:30: return new
jsEvent(name);
On 2017/07/14 00:04:42, lazyboy wrote:
> Should we not use eventOpts here?

We should!  Thanks for catching this.  I've expanded the test to catch this as
well (since it would have been a bug).  (I mistakenly thought that
webview.contextMenus.onClick.addListener would have done the trick - apparently
we also need to test webview.contextMenus.create({onclick: function() {}});)

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/res...
File extensions/renderer/resources/guest_view/web_view/web_view_events.js
(right):

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/res...
extensions/renderer/resources/guest_view/web_view/web_view_events.js:44: return
new jsEvent(name, schema, options);
On 2017/07/14 00:04:42, lazyboy wrote:
> Can we DCHECK options.supportsLazyEvents == false?

Good idea; done.

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/res...
File extensions/renderer/resources/messaging.js (right):

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/res...
extensions/renderer/resources/messaging.js:29: var supportsLazyListeners =
false;
On 2017/07/14 00:04:42, lazyboy wrote:
> Do we need true here?

Nope, see previous comment.

[commit-bot: I haz the power, 2017-07-14 15:40:52]

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

[commit-bot: I haz the power, 2017-07-14 15:40:53]

Dry run: Try jobs failed on following builders:
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)

[lazyboy, 2017-07-17 23:38:50]

lgtm

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/bin...
File extensions/renderer/bindings/api_binding.cc (right):

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/bin...
extensions/renderer/bindings/api_binding.cc:323: bool
temp_supports_lazy_listeners = false;
On 2017/07/14 15:37:54, Devlin wrote:
> On 2017/07/14 00:04:42, lazyboy wrote:
> > On 2017/07/10 15:33:02, jbroman wrote:
> > > nit: Why is it so bad that we have to prevent "supportsLazyListeners:
true"
> > from
> > > being specified that we force it to false (which is neither default nor
what
> > was
> > > specified) in that case?
> > I like it this way though: API schema owners need not worry about lazy
> listeners
> > and extension system takes care of the default: listeners from lazy context
> > would become lazy automatically. The slight deviation is only for webview
and
> we
> > should not expect usages of this outside of webview events.
> > 
> >  It seems simpler to do:
> > > 
> > > if (options->GetBoolean("supportsLazyListeners",
&supports_lazy_listeners))
> {
> > >   DCHECK(!supports_lazy_listeners)
> > >       << "Don't specify supportsLazyListeners: true; it's the default.";
> > > }
> > 
> 
> I think jbroman@ was just saying that it seems excessive that we have a temp
> variable here to guard against supports_lazy_listeners ever, ever being
> specified as true (as opposed to *still* DCHECKing, but taking out the extra
> temp variable).
Sure, I thought it was to consider removing the restriction, this SG.
  I think it's a fair point - specifying true isn't the end of
> the world, so as long as we still DCHECK (hopefully folks test! :P), it should
> be fine.

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/res...
File extensions/renderer/resources/messaging.js (right):

https://codereview.chromium.org/2973903002/diff/60001/extensions/renderer/res...
extensions/renderer/resources/messaging.js:29: var supportsLazyListeners =
false;
On 2017/07/14 15:37:54, Devlin wrote:
> On 2017/07/14 00:04:42, lazyboy wrote:
> > Do we need true here?
> 
> Nope, see previous comment.

Acknowledged.

[Devlin, 2017-07-18 21:07:57]

The CQ bit was checked by rdevlin.cronin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-07-18 21:08:13]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-07-18 21:11:10]

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

[commit-bot: I haz the power, 2017-07-18 21:11:11]

Dry run: Try jobs failed on following builders:
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[Devlin, 2017-07-18 22:20:40]

The CQ bit was checked by rdevlin.cronin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-07-18 22:20:53]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-07-18 22:39:13]

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

[commit-bot: I haz the power, 2017-07-18 22:39:14]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Devlin, 2017-07-18 23:12:37]

The CQ bit was checked by rdevlin.cronin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-07-18 23:12:46]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-07-19 00:27:04]

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

[commit-bot: I haz the power, 2017-07-19 00:27:05]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Devlin, 2017-07-19 01:50:40]

The CQ bit was checked by rdevlin.cronin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-07-19 01:50:59]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-07-19 02:55:24]

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

[commit-bot: I haz the power, 2017-07-19 02:55:26]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Devlin, 2017-07-19 16:05:38]

The CQ bit was checked by rdevlin.cronin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-07-19 16:05:49]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-07-19 17:16:59]

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

[commit-bot: I haz the power, 2017-07-19 17:17:00]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Devlin, 2017-07-19 17:46:31]

The CQ bit was checked by rdevlin.cronin@chromium.org

[Devlin, 2017-07-19 17:46:32]

The patchset sent to the CQ was uploaded after l-g-t-m from
jbroman@chromium.org, lazyboy@chromium.org
Link to the patchset: https://codereview.chromium.org/2973903002/#ps150001
(title: "onMessage event fix")

[commit-bot: I haz the power, 2017-07-19 17:46:46]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-07-19 21:26:39]

CQ is committing da patch.

Bot data: {"patchset_id": 150001, "attempt_start_ts": 1500486391795630,
"parent_rev": "724ac890c910d8633ef1428f0f38a222a6d4eb2a", "commit_rev":
"91f0c8a3cc9d78c32e914b74c920c26ccd748968"}

[commit-bot: I haz the power, 2017-07-19 21:27:00]

Description was changed from

==========
[Extensions Bindings] Introduce a supportsLazyListeners property

Right now, we determine whether to store the record of a lazy listener
in the extension prefs based only on the type of context - if the
context registering the listener is a lazy context (like an event page),
then we store a lazy listener in extension prefs.

This is incorrect for webview events.  Webview events are exposed on a
<webview> DOM object, but are implemented behind-the-scenes as
extension events (including the listener bookkeeping). However, having a
lazy listener for a webview event doesn't make sense:
- the only time a listener would be considered lazy is when the listener
  was added in a lazy context
- a lazy listener will only be used to wake up an inactive context
- webview events are tied to a specific webview
Thus, a lazy listener would only be used for a webview which has since
been torn down.

With this in mind, we can avoid registering any lazy listeners for
webview-related events. Introduce the key supportsLazyListeners into the
JSON schema and add it for webview events. When this key is present,
events don't register lazy listeners.

Wire this up for both native and JS-based bindings, and add unit tests
for the bindings and an end-to-end test to ensure that webview event
listeners will never be registered as lazy listeners.

A followup will add logic to clean up current prefs to remove traces of
the listeners.

BUG=736381
==========

to

==========
[Extensions Bindings] Introduce a supportsLazyListeners property

Right now, we determine whether to store the record of a lazy listener
in the extension prefs based only on the type of context - if the
context registering the listener is a lazy context (like an event page),
then we store a lazy listener in extension prefs.

This is incorrect for webview events.  Webview events are exposed on a
<webview> DOM object, but are implemented behind-the-scenes as
extension events (including the listener bookkeeping). However, having a
lazy listener for a webview event doesn't make sense:
- the only time a listener would be considered lazy is when the listener
  was added in a lazy context
- a lazy listener will only be used to wake up an inactive context
- webview events are tied to a specific webview
Thus, a lazy listener would only be used for a webview which has since
been torn down.

With this in mind, we can avoid registering any lazy listeners for
webview-related events. Introduce the key supportsLazyListeners into the
JSON schema and add it for webview events. When this key is present,
events don't register lazy listeners.

Wire this up for both native and JS-based bindings, and add unit tests
for the bindings and an end-to-end test to ensure that webview event
listeners will never be registered as lazy listeners.

A followup will add logic to clean up current prefs to remove traces of
the listeners.

BUG=736381

Review-Url: https://codereview.chromium.org/2973903002
Cr-Commit-Position: refs/heads/master@{#487991}
Committed:
https://chromium.googlesource.com/chromium/src/+/91f0c8a3cc9d78c32e914b74c920...
==========

[commit-bot: I haz the power, 2017-07-19 21:27:02]

Committed patchset #9 (id:150001) as
https://chromium.googlesource.com/chromium/src/+/91f0c8a3cc9d78c32e914b74c920...