STR:

1. Navigate to about:networking#networkid
2. Disconnect from active network
3. Hit the refresh button on about:networking#networkid

Expected result:

• "Link is up" should be false after refreshing

Actual result:

• "Link in up" is true after refreshing

When I turn the network on and off, I can't get the browser's observer for "network:offline-status-change" to fire. Not sure what else to try or dig into to understand what is going on here.

I tried it on MacOS and it works.

This must be OS 0or setup-specific problem.

Can you tell us more about your setup? Mostly interested in the OS.

I'm running Windows 10 Pro. I tried mozregression to see if I could find a range, but every version I tried has the same issue of the network link being up while there is no active connection to a network. Guess that means it's an OS specific issue. Let me know what other info I can provide.

Doing some more digging, I realize I have a few virtual adapters apparently but none of them have network access/valid IPs even when my main network adapter is connected to the internet. It also seems there's no kind of exception being thrown in nsNotifyAddrListener.cpp so mLinkUp is always set to true even those these other adapters are not connected to any network with internet access and my main network adapter is disconnected. It's strange because this issue doesn't appear in Windows 11 according to this comment on Bug 1789872. I'm not sure what else to try in order to investigate, but if you have any ideas, please let me know!

Maybe it has something to do with my machine having more than one network adapter? If I'm understanding CheckAdaptersAddresses correctly, the only time we set mLinkUp to false is when we successfully call GetAdaptersAddresses but there are no adapters to iterate through. Again, if I'm understanding correctly, this causes mLinkUp to be false which then should cause an update in the about:networking#networkid page. Maybe I'm on the wrong path through, figured I'd make a note of it regardless.

Set this to P3, since I think this might be an uncommon case.
Feel free to adjust the priority if you think this is important.

Kershaw -- Any way we could bump priority to a P2 for this one? We would ideally like to address the bug this is blocking (https://bugzilla.mozilla.org/show_bug.cgi?id=1789872) in the 107 release cycle if possible. Let me know if this sound feasible.

(In reply to Ray Fambro from comment #7)

Kershaw -- Any way we could bump priority to a P2 for this one? We would ideally like to address the bug this is blocking (https://bugzilla.mozilla.org/show_bug.cgi?id=1789872) in the 107 release cycle if possible. Let me know if this sound feasible.

Sure. We can bump this to P2. Since we are reaching the end of this cycle, I am afraid we can't promise this will be fixed in this cycle.
I can't reproduce this locally on my Windows 10 laptop, so It'd be really helpful if someone can provide STR for this. Thanks.

Hi Tim,

Looks like you can reproduce this locally.
Could you help me to get a log?
The steps are:

1. Make sure the network is connected.
2. Start Firefox by typing MOZ_LOG=nsNotifyAddr:5 ./mach run
3. Disconnect your network.
4. Attach the command line output to this bug.

Thanks.

Attached is the log when enabling the logger for nsNotifyAddr.

Here are some updated STR, I believe it has something to do with multiple enabled network adapters:

1. Have more than one enabled network adapter

• For example, I have two VMware virtual ethernet adapters for my machine to run VMs

2. Be connected to the internet on your active network adapter and not connected to the internet on your secondary network adapter.

• In my case, one of the VMware virtual ethernet adapters is enabled with no network access, my wi-fi adapter is enabled and connected to the internet while the rest of my network adapters have been disabled via "Network and Internet -> Network Connections" in the Control Panel.

3. Go to about:networking#networkid and take note of the network ID
4. Disconnect from the active network

• I've been using the airplane mode to disconnect but you should be able to trigger this by forgetting the internet network as well

5. Refresh about:networking#networkid
6. The network ID has changed but the link is up is still true even though there is no internet connection.

If you only have one enabled network adapter, this bug will not reproduce. I disabled all of my other network adapters except for my wi-fi adapter and then disconnected from the network. The page then updated the status and set "link is up" to false.

Hopefully that will allow you to reproduce the issue, but please let me know if I can provide more info.

OK, now I understand the problem.
The problem is that LinkUp being true doesn't always mean that Firefox has the connectivity to the internet. Note that connectivity to the internet here means that Firefox can reach to a public web site (e.g., example.com).

I think maybe nsINetworkConnectivityService can match your requirement. Could you check if nsINetworkConnectivityService is enough for you?

Okay, thanks for that clarification! I completely misunderstood what LinkUp meant here. I think nsINetworkConnectivityService is what we want to use for Firefox View instead. I was able to use nsINetworkConnectivityService.IPv4 and see it change value as I disconnected and reconnected to the internet even when I had other network adapters enabled (and these other ones are not able to connect to a public web site which is expected).

I think the only issue I'm seeing is that I don't know how to listen for/observe when nsINetworkConnectivityService.IPv4 changes value. With the nsIIOService we can listen to "network:offline-status-changed" which is established in the IDL but there's no equivalent in the nsINetworkConnectivityService. Any suggestions? It's about the end of day for me so there's probably a really obvious answer to this but my brain is out of power :)

I think the only issue I'm seeing is that I don't know how to listen for/observe when nsINetworkConnectivityService.IPv4 changes value. With the nsIIOService we can listen to "network:offline-status-changed" which is established in the IDL but there's no equivalent in the nsINetworkConnectivityService. Any suggestions? It's about the end of day for me so there's probably a really obvious answer to this but my brain is out of power :)

I think we can add something like network:connectivity-status-changed to notify that nsINetworkConnectivityService.IPv4 is changed.
I'll try to fix this next week.

It feels like it would be useful to have documentation on the IO service, network link service, and network connectivity service and what they all do/don't do, and what to use them for. I don't see any consumers of nsINetworkConnectivityService in the tree, but there are a bunch of consumers of nsINetworkLinkService. It's not clear to me if sync, the media code, and various other things, should all migrate to nsINetworkConnectivityService, but if so (which I think is what this is saying?), that seems like something we should track. Also, if outside consumers just generally shouldn't use nsINetworkLinkService, perhaps it shouldn't be an interface and should be kept private to the networking code...

I also couldn't figure out from looking at the nsINetworkConnectivityService interface / source what the states mean and how they relate to captive portal detection / TRR - ie is IPv4 going to be 0, 1 or 2 when connected to a network with a captive portal that I haven't bypassed yet (or where TRR/DoH is blocked)?

(In reply to :Gijs (he/him) from comment #14)

It feels like it would be useful to have documentation on the IO service, network link service, and network connectivity service and what they all do/don't do, and what to use them for. I don't see any consumers of nsINetworkConnectivityService in the tree, but there are a bunch of consumers of nsINetworkLinkService. It's not clear to me if sync, the media code, and various other things, should all migrate to nsINetworkConnectivityService, but if so (which I think is what this is saying?), that seems like something we should track. Also, if outside consumers just generally shouldn't use nsINetworkLinkService, perhaps it shouldn't be an interface and should be kept private to the networking code...

Sorry for the confusion. I didn't want to propose to replace nsINetworkLinkService with nsINetworkConnectivityService.
In summary:

• nsINetworkLinkService provides the information about whether there is an usable interface for establishing a network connection. Firefox gets this information via OS provided APIs, so this information is accurate and real-time.
• nsINetworkConnectivityService tells whether Firefox can successfully get the HTTP response back from http://detectportal.firefox.com. This information might be incorrect and not reliable, since there could be a race between receiving HTTP response and network change.
  IMO, the information provided by these two services are different. We should use them based on what we need.

Let's go back to the issue of this bug.
Tim, do you have an idea how many users are affected by this? How many users have virtual adapters installed?
I'd imagine maybe the number is not a lot.

(In reply to Kershaw Chang [:kershaw] from comment #15)

Tim, do you have an idea how many users are affected by this? How many users have virtual adapters installed?
I'd imagine maybe the number is not a lot.

I unfortunately don't have a good idea of how many people are affected by this. I also have no idea if we have telemetry for this case. People running VMWare, VirtualBox, and most likely other virtualization software would be affected by this. I think people who use a VPN might be affected as well, but I can't confirm that.

I'm also not sure whether or not we'd have telemetry on this, but my first assumption was that this would affect VPN users....and I'd think that number would actually be high.

So this issue is reproducible with Mozilla VPN but not with Viscosity, which are the only VPNs that I have. Not sure if that tilts things one way or the other, but it looks like VPN users could be affected by this depending on how their VPN provider operates. It seems like when Viscosity loses network connection, it turns itself off. Mozilla VPN stays enabled but is aware there is no internet network connection available. I'm sure there are other VPN providers that behave in a similar way.

Thanks for the follow up Tim. My assumption now is that we cannot address this issue in time to land in 107. So I think it should be fine to downgrade to a P3 and further investigate.

Did some testing for a different bug and I'm able to reproduce this bug on Mac and Linux, as far as I understand it.

1. Load Ubuntu 22.04 or MacOS Monterrey 12.4
2. Have a VPN app. I'm using Mozilla VPN in this case.
3. Enable VPN
4. Go to about:networking#networkid and take note of the current Network ID
5. Note that "Link is up" and "Link status is known" are both true
6. Disconnect from the internet while keeping the VPN application enabled
7. With Mozilla VPN, the application does notice there's no internet action and displays that information in app
8. Use the "Refresh" button on about:networking#networkid
9. Notice the Network ID has changed from step 4 but both "Link is up" and "Link status is known" are true.

Given these steps I think we should change this bug, or the newly filed one, to note that all platforms are affected.