Blink: make the dispatchDeviceEvent virtual to allow overrides in subclasses.

Blink: make the dispatchDeviceEvent virtual to allow overrides in subclasses.

The default dispatching of DeviceSensorEventController is on DOMWindow.
Battery Status API does not dispatch on window, so this change is to
allow for a more generic dispatch in deriving classes.

BUG=

[abarth-chromium, 2014-04-09 15:44:24]

This change is probably fine, but we should wait to make it until we actually
have someone that overrides this function.  If we already have an override that
doesn't work properly today, we should have a test that demonstrates it.

[timvolodine, 2014-04-09 15:53:59]

On 2014/04/09 15:44:24, abarth wrote:
> This change is probably fine, but we should wait to make it until we actually
> have someone that overrides this function.  If we already have an override
that
> doesn't work properly today, we should have a test that demonstrates it.

yes this change is intended for https://codereview.chromium.org/212643010/,
otherwise it cannot echo most recent data when a new 'controller' registers with
dispatcher.

[timvolodine, 2014-04-10 12:08:09]

On 2014/04/09 15:53:59, timvolodine wrote:
> On 2014/04/09 15:44:24, abarth wrote:
> > This change is probably fine, but we should wait to make it until we
actually
> > have someone that overrides this function.  If we already have an override
> that
> > doesn't work properly today, we should have a test that demonstrates it.
> 
> yes this change is intended for https://codereview.chromium.org/212643010/,
> otherwise it cannot echo most recent data when a new 'controller' registers
with
> dispatcher.

Actually I am not sure if this is really needed. Battery API calls
startUpdating() at constructor time and echoing back any existing data could
produce inconsistent behavior, e.g. depending on when the addEventListener is
called it may or may not receive a callback with cached data. I guess for now we
should not echo existing data, but only dispatch real changes coming from the
platform.. does that sound reasonable?

[timvolodine, 2014-04-10 12:11:26]

+ Srini: added a comment regarding the dispatch of cached data.

[Srini, 2014-04-10 17:18:42]

On 2014/04/10 12:11:26, timvolodine wrote:
> + Srini: added a comment regarding the dispatch of cached data.

Just want to understand will this helps a case to echo possible updated data in
a brief period after stopUpdating? (page visibility or suspend/resume?)

[timvolodine, 2014-04-10 18:17:14]

On 2014/04/10 17:18:42, Srini wrote:
> On 2014/04/10 12:11:26, timvolodine wrote:
> > + Srini: added a comment regarding the dispatch of cached data.
> 
> Just want to understand will this helps a case to echo possible updated data
in
> a brief period after stopUpdating? (page visibility or suspend/resume?)

stopUpdating stops the one-shot timer so no echos after that. The original idea
was to fire an event as soon as a controller registers with dispatcher if any
cached data is available. This hold for 'deviceorientation' but does not seem
necessary for battery status, as no event listener may even be present at the
time of one-shot timer firing.

[Srini, 2014-04-14 05:26:18]

On 2014/04/10 18:17:14, timvolodine wrote:
> On 2014/04/10 17:18:42, Srini wrote:
> > On 2014/04/10 12:11:26, timvolodine wrote:
> > > + Srini: added a comment regarding the dispatch of cached data.
> > 
> > Just want to understand will this helps a case to echo possible updated data
> in
> > a brief period after stopUpdating? (page visibility or suspend/resume?)
> 
> stopUpdating stops the one-shot timer so no echos after that. The original
idea
> was to fire an event as soon as a controller registers with dispatcher if any
> cached data is available. This hold for 'deviceorientation' but does not seem
> necessary for battery status, as no event listener may even be present at the
> time of one-shot timer firing.

Thank you for the explanation.

[timvolodine, 2014-10-22 11:41:40]

closing this patch as it has been superseded by crrev.com/315573002.