Listen to WM_TIMECHANGE messages in RenderViewHostImpl on windows

Listen to WM_TIMECHANGE messages in RenderViewHostImpl on windows

This message is broadcasted to all top-level HWNDs when the system time
changes, including when the time zone is changed (even if this doesn't actually
change the time, for instance when changing between two time zones with the same
offset from UTC but different daylight savings time rules). This propagates
the notification to render processes so they can update their time zone caches.

BUG=288697

[jamesr, 2014-03-11 01:04:14]

John - could you advise on the best place to put this?  I'd like this to live
somewhere in content since it is something all content embeddings would probably
want, but it's a bit ugly to hide platform-specific code directly in
r_v_h_impl.cc.  I think Mark might want to wire up something very similar on OS
X.

[jam, 2014-03-11 15:56:55]

On 2014/03/11 01:04:14, jamesr wrote:
> John - could you advise on the best place to put this?  I'd like this to live
> somewhere in content since it is something all content embeddings would
probably
> want, but it's a bit ugly to hide platform-specific code directly in
> r_v_h_impl.cc.  I think Mark might want to wire up something very similar on
OS
> X.

btw i just saw a cl from Jochen moving the method to RenderProcessHost

perhaps RenderProcessHost can create a TimeObserver with a callback that's bound
to a method on RPH which sends the IPC? then there would be
time_observer_win.cc, time_observer_mac.cc etc with platform specific changes?

[Mark Mentovai, 2014-03-11 16:07:51]

This is where it’s going to get hairy. We don’t really need one system-level
observer per RPH on the Mac. We just need one system-level observer for the
browser process as a whole.

[jam, 2014-03-11 16:43:28]

On 2014/03/11 16:07:51, Mark Mentovai wrote:
> This is where it’s going to get hairy. We don’t really need one system-level
> observer per RPH on the Mac. We just need one system-level observer for the
> browser process as a whole.

good point, it's also the same on windows. let's make it per browser process and
be owned by BrowserMainLoop. there could be one shared method among all the
platform-specific files that sends the notification to all RPHs.

[Mark Mentovai, 2014-03-11 16:54:04]

That works for me.

[jamesr, 2014-03-11 21:48:59]

PTAL - this hangs a TimeZoneMonitorWin off of the BrowserMainLoop that on
notification iterates through all RenderWidgetHosts.  It'd be pretty easy to
migrate this to iterating through RenderProcessHosts if we move the IPC to
there.  I think it should be pretty easy to set up the mac observer in a similar
fashion.

[Mark Mentovai, 2014-03-11 21:59:08]

Yeah, I can make the Mac implementation live in the same place as this, and we’d
wind up sharing the loop over RWHs or RPHs.

We should also be able to adapt the existing Chrome OS code to at least share
the same loop.

[jamesr, 2014-03-14 23:06:15]

Patch set #3 does a loop over process hosts since that's where
NotifyTimezoneChanged() lives as of
http://src.chromium.org/viewvc/chrome?view=revision&revision=256876

[jam, 2014-03-17 17:08:29]

On 2014/03/14 23:06:15, jamesr wrote:
> Patch set #3 does a loop over process hosts since that's where
> NotifyTimezoneChanged() lives as of
> http://src.chromium.org/viewvc/chrome?view=revision&revision=256876

aren't we going to make this cross platform? if so it seems that browsermainloop
should have a cross platform type