I think steps 2 and 3 don't do anything on purpose. Linux doesn't take down the interface when the cable is removed. This is so you can plug it back in and continue where you left off. This is an operating system kernel feature which Chrome is just reflecting.

Sending to //net where the actual detection is done for final determination of whether this is the intended behaviour.

That does sounds broken.

I can also reproduce on Linux.

When I looked at chrome://net-internals/, we do get network change notifications indicating the wired connection is disconnected and then reconnected, so it seems unexpected that the online/offline event in the web platform is not getting the right info.

> I think steps 2 and 3 don't do anything on purpose. Linux doesn't take down the interface when the cable is removed. This is so you can plug it back in and continue where you left off. This is an operating system kernel feature which Chrome is just reflecting.

The device isn't taken down, but it does lose all IP addresses and the IFF_RUNNING property, so since there is no way to communicate, navigator.onLine should transition to false.  https://html5demos.com/nav-online/ corroborates the fact that it fails to go to false on linux now.

It looks like the NetworkChangeNotifier's OnNetworkChanged() signal goes to CONNECTION_NONE according to chrome://net-internals, like eroman@ noted, so navigator.onLine should be going to false.  This seems like a problem above //net, either in network servicification or blink.

I think I tracked this down:  Way back in r349739 BrowserOnlineStateObserver was changed to a net::NetworkChangeNotifier::MaxBandwidthObserver.  During servicification of the NetworkChangeNotifier, see  Issue 754709 , all NetworkChangeNotifier observers outside //net of the OnIPAddressChanged(), OnConnectionTypeChanged(), OnDNSChanged() and OnNetworkChanged() signals were changed to go through the NetworkConnectionTracker::NetworkConnectionObserver interface.  However MaxBandwidthObservers were never converted over...of which there is only one: BrowserOnlineStateObserver

So BrowserOnlineStateObserver needs to be converted to a NetworkConnectionTracker::NetworkConnectionObserver.

assigning to robby for more triage C#5. seems like we should fix it prior to stable but not sure. 

I haven't been able to reproduce this on 69.0.3497.100, with or without the network service enabled. Paul, what version of chrome did you test on?

Not sure, perhaps 69.0.3497.81 or 69.0.3497.92.
https://html5demos.com/nav-online/ stayed "online" when I pulled the Ethernet cable on my HP z840.

I was able to reproduce this. The issue appears to be in NetworkChangeNotifierLinux, which initializes last_type_ to CONNECTION_NONE, but never sets it correctly once the connection type is known. When you disconnect the ethernet cable, NetworkChangeNotifierLinux sees it, gets the new connection type (CONNECTION_NONE), but doesn't notify observers because it thinks the type didn't change. Adding 'last_type_ = GetCurrentConnectionType();' to Init seems to fix it, but I'll leave the fix to someone more familiar with this code.

As for migrating BrowserOnlineStateObserver to NetworkConnectionTracker, we should do that, but it doesn't currently provide the max bandwidth information, which is needed.

I think comment 9 is a different issue as the steps to reproduce are different.

> As for migrating BrowserOnlineStateObserver to NetworkConnectionTracker, we should do that, but it doesn't currently provide the max bandwidth information, which is needed.

I don't think the max bandwidth information is necessary anymore.

I was testing using the method described in comment 8, so I believe it's the same issue. 

NetworkConnectionTracker is backed by NetworkChangeNotifier under the hood, so any issues with it will show up in NetworkConnectionTracker as well. In this particular case, the fact that NetworkChangeNotifier never notifies of the connection change means NetworkConnectionTracker won't either.

The max bandwidth information is passed to the renderer and is used in the Network Information API.
https://cs.chromium.org/chromium/src/content/common/renderer.mojom?sq=package:chromium&dr&l=205
https://wicg.github.io/netinfo/#the-networkinformation-interface

Can the presence or absence of other network interfaces affect the success to retry this problem? For example, several docker containers, vpn?

mmenke@: how can I run Chrome with servicification enabled and disabled?  is there a way to know if it's running with servicification enabled or disabled?

--enable-features=NetworkService to enable.  And to disable, it's --disable-features=NetworkService.

WRT comment #5: I don't think this is the cause of this issue.  I tried the flags from comment #15 and wasn't able to reproduce this bug either way.  I still fear this will be a problem for servicification, but I'm unsure how it's working now; perhaps there is still a NetworkChangeNotifier instance running in the browser process even when servicification is enabled.

WRT comment #9: I ran into this bug.  Perhaps that's the issue I was reproducing in comment #4 and #5.  I put up https://chromium-review.googlesource.com/c/chromium/src/+/1256285 to fix this.

WRT comment #13: Yes, VPNs and VMs can add network interfaces that looks like they're offering an Internet connection.  This has been discussed in Issue 231912.  Can you please include the output of ifconfig when you think the machine is offline but Chrome thinks the machine is online?

Yeah, there's still a NetworkChangeNotifier instance running in the browser process when the network service is enabled. There are several things that haven't been migrated over to the NetworkConnectionTracker yet, and a few others that depend on NetworkChangeNotifier APIs other than the NetworkChangeObserver ones, like BrowserOnlineStateObserver as you mentioned in #5, so it'll be a while before we can get rid of the browser process's instance of it.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e1ee0349dec380878c4490d565fbfd6eea32b455

commit e1ee0349dec380878c4490d565fbfd6eea32b455
Author: Paul Jensen <pauljensen@chromium.org>
Date: Tue Oct 02 23:35:57 2018

Initialize network connection type

Previously it was always initialized to CONNECTION_NONE, so if
the first transition is to CONNECTION_NONE, it would not send out
a notification.

Bug:  883208 
Change-Id: I583003a8d2d7160c88165a72194ca84eb9f42925
Reviewed-on: https://chromium-review.googlesource.com/c/1256285
Reviewed-by: Misha Efimov <mef@chromium.org>
Commit-Queue: Paul Jensen <pauljensen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#596042}
[modify] https://crrev.com/e1ee0349dec380878c4490d565fbfd6eea32b455/net/base/network_change_notifier_linux.cc

Waiting for response to my ifconfig query in comment #16.

I have single physical ethernet interface named "enp3s0". My ifconfig results(tx/rx was removed as useless information):



1. Disable network connection in NetworkManager:


br-3c21f2ee2e3a: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.25.0.1  netmask 255.255.0.0  broadcast 172.25.255.255
        inet6 fe80::42:aff:fe5a:3fe1  prefixlen 64  scopeid 0x20<link>
        ether 02:42:0a:5a:3f:e1  txqueuelen 0  (Ethernet)

br-bfee99e4e800: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.18.0.1  netmask 255.255.0.0  broadcast 172.18.255.255
        inet6 fe80::42:cff:fed0:75ac  prefixlen 64  scopeid 0x20<link>
        ether 02:42:0c:d0:75:ac  txqueuelen 0  (Ethernet)

br-d68474e6ec7d: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.19.0.1  netmask 255.255.0.0  broadcast 172.19.255.255
        ether 02:42:c2:a6:91:3a  txqueuelen 0  (Ethernet)

br-d8b59f68257d: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.20.0.1  netmask 255.255.0.0  broadcast 172.20.255.255
        ether 02:42:30:df:87:99  txqueuelen 0  (Ethernet)

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        inet6 fe80::42:bdff:fe11:cd5f  prefixlen 64  scopeid 0x20<link>
        ether 02:42:bd:11:cd:5f  txqueuelen 0  (Ethernet)

enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 40:8d:5c:79:e3:9f  txqueuelen 1000  (Ethernet)

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)

veth1dc82fe: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::244e:7fff:fe5b:2826  prefixlen 64  scopeid 0x20<link>
        ether 26:4e:7f:5b:28:26  txqueuelen 0  (Ethernet)

vethda2f0f2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::dc0f:edff:fe4b:e83f  prefixlen 64  scopeid 0x20<link>
        ether de:0f:ed:4b:e8:3f  txqueuelen 0  (Ethernet)

virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.124.1  netmask 255.255.255.0  broadcast 192.168.124.255
        ether 52:54:00:91:52:75  txqueuelen 1000  (Ethernet)




2. Connection enabled in NetworkManager, but cable was unplugged:


br-3c21f2ee2e3a: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.25.0.1  netmask 255.255.0.0  broadcast 172.25.255.255
        inet6 fe80::42:aff:fe5a:3fe1  prefixlen 64  scopeid 0x20<link>
        ether 02:42:0a:5a:3f:e1  txqueuelen 0  (Ethernet)

br-bfee99e4e800: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.18.0.1  netmask 255.255.0.0  broadcast 172.18.255.255
        inet6 fe80::42:cff:fed0:75ac  prefixlen 64  scopeid 0x20<link>
        ether 02:42:0c:d0:75:ac  txqueuelen 0  (Ethernet)

br-d68474e6ec7d: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.19.0.1  netmask 255.255.0.0  broadcast 172.19.255.255
        ether 02:42:c2:a6:91:3a  txqueuelen 0  (Ethernet)

br-d8b59f68257d: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.20.0.1  netmask 255.255.0.0  broadcast 172.20.255.255
        ether 02:42:30:df:87:99  txqueuelen 0  (Ethernet)

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        inet6 fe80::42:bdff:fe11:cd5f  prefixlen 64  scopeid 0x20<link>
        ether 02:42:bd:11:cd:5f  txqueuelen 0  (Ethernet)

enp3s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 40:8d:5c:79:e3:9f  txqueuelen 1000  (Ethernet)

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)

veth1dc82fe: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::244e:7fff:fe5b:2826  prefixlen 64  scopeid 0x20<link>
        ether 26:4e:7f:5b:28:26  txqueuelen 0  (Ethernet)

vethda2f0f2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::dc0f:edff:fe4b:e83f  prefixlen 64  scopeid 0x20<link>
        ether de:0f:ed:4b:e8:3f  txqueuelen 0  (Ethernet)

virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.124.1  netmask 255.255.255.0  broadcast 192.168.124.255
        ether 52:54:00:91:52:75  txqueuelen 1000  (Ethernet)

Looks like your VMs create lots of interfaces that are up and running and have non-local IP addresses.  I'm not sure if there is a good way of differentiating these from say a normal Ethernet interface.

Able to reproduce the issue on ubuntu 17.10 using chrome reported version #69.0.3497.81.
Verified the fix on ubuntu 17.10 using chrome version #71.0.3573.0 as per the comment #8.
Attaching screen shots for reference.
Observed that on navigating to https://html5demos.com/nav-online/, the status showed as "offline" on unplugging the ethernet cable.
Hence, the fix is working as expected. 
Adding the verified labels.

Thanks...!!

Deleted: 883208_1.png 156 KB

	883208_1.png 156 KB View Download

Deleted: 883208_2.png 89.3 KB

	883208_2.png 89.3 KB View Download