Bug 939318 added some stuff that allows listeners to respond to a NS_NETWORK_LINK_TOPIC CHANGED event. We need to send this appropriately on Android.

Comment on attachment 8445247 [details] [diff] [review] Send network link change events Review of attachment 8445247 [details] [diff] [review]: ----------------------------------------------------------------- As discussed on IRC, I'm concerned that we'll miss link changes where the type doesn't change, like moving from one WiFi AP to another or switching networks on a dual SIM phone

:bagder has some wip that builds a checksum for the windows networking state (current addresses and interfaces, etc..).. you might coordinate he's on vacation for a bit but I'm thinking of bug 939318

(In reply to Patrick McManus [:mcmanus] from comment #3) > :bagder has some wip that builds a checksum for the windows networking state > (current addresses and interfaces, etc..).. you might coordinate > > he's on vacation for a bit but I'm thinking of bug 939318 One thing Brad and I considered was just sending the change event whenever Android tells us there was a change. Would that cause any bad stuff if nothing important did actually change? Presumably it would just cause a few extra pings?

Comment on attachment 8445347 [details] [diff] [review] Send network link change events Review of attachment 8445347 [details] [diff] [review]: ----------------------------------------------------------------- I think for the moment this is fine, but a lot of it going to depend on exactly how bagder handles the notifications - so he should consider this and any changes before his other code lands.. I know it will lead to clearing of some pretty important caches, so we want to avoid that if e.g. the wifi signal just blips on and off as it goes in and out of your pocket.

I think it is fine to send the event more often rather than too seldom (if there's ever such a choice), but I added a checksum for the Windows backend in Bug 939318 since its notifying system is very trigger-happy and caused a large amount of events to happen without me seeing any "interesting" info changing. I'm sure that will differ on specific backend system functionality. And again, triggering CHANGED a little too often will "just" hurt some caches and some performance but will be better than missing a network change event that then instead will end up with stalls and annoyed users.

Backed out for frequent Android x86 robocop crashes. https://hg.mozilla.org/integration/mozilla-inbound/rev/13df548b6591 https://tbpl.mozilla.org/php/getParsedLog.php?id=48969085&tree=Mozilla-Inbound

This looks like we try to call FlushCache() on a null nsHostResolver. :bagder can you have a look?

Daniel/Patrick, whoever can get to this first :)

Comment on attachment 8496103 [details] [diff] [review] Guard against null resolver when flushing DNS cache Review of attachment 8496103 [details] [diff] [review]: ----------------------------------------------------------------- I'm gonna give a drive-by r+ here, taking Daniel's review because it's late in Europe :) Looks like mHostResolver can be null if we've previously been told to go offline. So, null checking seems like the right thing to do.

remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/ea3b44a4b97a remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/473717699910

Comment on attachment 8496103 [details] [diff] [review] Guard against null resolver when flushing DNS cache Review of attachment 8496103 [details] [diff] [review]: ----------------------------------------------------------------- steve's review is fine

https://hg.mozilla.org/mozilla-central/rev/ea3b44a4b97a https://hg.mozilla.org/mozilla-central/rev/473717699910