Intent to Ship: Network Information API

[Josh Karlin]

Contact emails: jka...@chromium.org

Spec: http://w3c.github.io/netinfo/ (Editor's Draft)

Summary: Exposes the network connection type to window and workers via an attribute and adds an event to notify of connection type change.  Some expected use cases are documented in http://w3c-webmob.github.io/netinfo-usecases/.

Link to intent to implement: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/R5yYtHEPiw4

Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?  Android and ChromeOS have complete support.  Windows, Mac, and Linux report "Unknown" when there is a network connection and "None" otherwise.  Improvements to the desktop types are in the works.

Demo link: None

Compatibility Risk

Firefox shipped on Android and FFOS in 31.  Desktop support coming.

OWP launch tracking bug: http://crbug.com/368358

Link to entry on the feature dashboard: 

http://www.chromestatus.com/features/6338383617982464#network

[Peter Beverloo]

Do you have an idea when Windows, Mac and Linux will be able to identify the actual type of connection (none vs. ethernet or wifi is probably the interesting case here)?

Is what we're shipping compatible with Firefox' implementation? It's too bad that we don't know Apple's opinion on this API.

Thanks,

Peter

[Josh Karlin]

Do you have an idea when Windows, Mac and Linux will be able to identify the actual type of connection (none vs. ethernet or wifi is probably the interesting case here)?

We had ethernet and wifi support in Windows but reverted it because the query added to startup time.  We'll fix that very soon.  Mac should have ethernet/wifi shortly after Windows as we have the logic to determine types, we just need to use it.  Linux eta is unknown.

 

Is what we're shipping compatible with Firefox' implementation? It's too bad that we don't know Apple's opinion on this API.

Yes, Firefox has implemented the same API.

[Mounir Lamouri]

On Fri, 25 Jul 2014, at 23:13, 'Josh Karlin' via blink-dev wrote:
> *Is this feature supported on all five Blink platforms (Windows, Mac,
> Linux, Chrome OS and Android)? *Android and ChromeOS have complete

> support. Windows, Mac, and Linux report "Unknown" when there is a
> network
> connection and "None" otherwise. Improvements to the desktop types are
> in
> the works.

Wouldn't that be more honest to disable the API on Desktop instead of
returning dummy values? Returning "None" or "Unknown" seems to do more
harm than good.

-- Mounir

[Ehsan Akhgari]

That is the reason we have not enabled the API on desktop yet, FWIW.  The thinking is that you need to feature detect the API anyway, so there is probably less harm in exposing in some Firefox environments than the usual.

Cheers,
Ehsan

[Josh Karlin]

Wouldn't that be more honest to disable the API on Desktop instead of
returning dummy values? Returning "None" or "Unknown" seems to do more
harm than good.

That would be fine with me.

[Darin Fisher]

LGTM

[Josh Karlin]

The CLs to restrict the API to Android, ChromeOS, and IOS are in review: 

https://codereview.chromium.org/422933003/

https://codereview.chromium.org/424823002/

[TAMURA, Kent]

LGTM2.

- Shipping status of Firefox is good.

- I don't think browser implementation status differences would make serious compatibility issues because this type of information is not critical for many applications.

--
TAMURA Kent
Software Engineer, Google

[Dimitri Glazkov]

LGTM3.

[jka...@chromium.org]

After *cough* three years *cough* the desktop platforms (OSX, Linux, and Mac) are ready to have network information (navigator.connection) switched on by default. I don't believe a separate intent-to-ship is necessary? But I at least wanted to give a heads up here.

Josh

[Chris Harrelson]

Hi,

Is there any change to the compatibility landscape? Did more browsers implement?

Also, please make sure there is an up-to-date chromestatus.com entry listing the latest platform implementation status.

Chris

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/81cd4a8b-b6a1-4abf-81ed-8bbe9230224b%40chromium.org.

[Josh Karlin]

Updated ChromeStatus. Firefox has moved from implementing to shipped on mobile. No other support to my knowledge.

[Chris Harrelson]

Ok. And it sounds like the specification is in about the same state as before? Has it seen a TAG review or any further standardization acceptance process?

Strangely, MDN still says no support even after all this time. That should be updated.

Chris

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAANMuaOdonFyPjmy_ez5m_xULFGEn7c%2B5ksBnXPX7wihX2nXLA%40mail.gmail.com.

[Josh Karlin]

If you hit the 'mobile' tab you'll see it on https://developer.mozilla.org/en-US/docs/Web/API/NetworkInformation.

What I'm launching here is the same API as launched previously (connection.type and downlinkMax). There have been recent attributes added (effectiveType, downlink, and rtt) and those changes have their own intent thread.

No TAG review or further standardization to my knowledge, but Ilya would know better.

Josh

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_e11GuY-Pbv5suwt%3DFvYv7fWeTiBgHuLhtzuYeUMo4GA%40mail.gmail.com.

[Boris Zbarsky]

On 5/31/17 12:35 PM, Josh Karlin wrote:
> What I'm launching here is the same API as launched previously
> (connection.type and downlinkMax).

Note that these are precisely the parts of this API that are most
problematic and least likely to get buy-in from other browsers in their
current form.

Yes, I'm aware Firefox on Android ships them. That happened before we
had our current intent process in place and hence without effective API
owner review. I don't believe we have plans to add these attributes on
desktop in their current form in Firefox, for the reasons mentioned
earlier in this thread and in the Firefox intent thread that aimed to
ship them on desktop.

Again, this is mostly an informational thing in terms of what at least
one other vendor is thinking here.

-Boris

[Philip Jägenstedt]

Given the skepticism about these 2 attributes we've seen here and on the other thread, I think it'd be best to have a new Intent to Ship for the missing platforms. We should seriously consider if removing them is the better path long term, in which case we don't want to spread them further.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/917b86a5-a8f2-93d0-d2f8-dfdf445f2c58%40mit.edu.

[Ilya Grigorik]

- NetInfo.type usage is ~0.9% [1]

- NetInfo.downlinkMax usage is ~0.5% [2]

The former is used by some sites as a crude "metered" signal: if type is cellular then X, otherwise Y. Yes, it's an imperfect signal but it is still directionally right and can be refined via the latter - e.g. if type is cellular and downlinkMax ~2G then X, otherwise Y. Also, as noted in NQE i2s [3], {effectiveType, rtt, downlink} are building on top of downlinkMax, so I don't think we can "deprecate" it as such. 

Perhaps downlink can subsume downlinkMax as a combined end-to-end and first-hop signal, but even there, I think there is merit in helping developers understand if the estimate provided by `downlink` is based on active measurement or the connection type of the first hop. In short, I think there are legitimate use cases for all of these attributes to co-exist -- yes, it's a nuanced API, but that reflects the complexity of the problem space and we should empower developers to experiment and decide on their own strategy for how to navigate this space.

Related GH issue: https://github.com/WICG/netinfo/issues/60

As a next step here, I'd propose we iterate on ^ issue and, once resolved, circle back on this thread.

ig

[3] https://groups.google.com/a/chromium.org/d/msg/blink-dev/UVfNMH50aaQ/vWg_8AeHBwAJ

[Philip Jägenstedt]

It sounds like the 3 new attributes don't entirely remove the need for the 2 old ones, in which case we certainly shouldn't rush to remove them. As you suggest, let's wait for https://github.com/WICG/netinfo/issues/60 to run its course, to see if we could find something that's more likely to be implemented and shipped everywhere, or not.