Intent to Ship: Web Bluetooth

[Jeffrey Yasskin]

Contact emails

jyas...@chromium.org, sch...@chromium.org, anim...@google.com

Spec

https://webbluetoothcg.github.io/web-bluetooth/

We've requested a TAG review: https://github.com/w3ctag/spec-reviews/issues/139.

Summary

Allow websites to communicate with user-selected Bluetooth Low Energy peripherals over the GATT protocol.

In M56, we want to ship the implemented subset identified at https://github.com/WebBluetoothCG/web-bluetooth/blob/master/implementation-status.md#gatt-communication-api. We intend to ship using a Finch flag so we can abort if something comes up during the rest of the Origin Trial.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/topic/blink-dev/pfNeo5cFXCk/discussion

“Intent to Experiment” and results

https://groups.google.com/a/chromium.org/d/topic/blink-dev/coyvHj1u2Z8/discussion

Results at https://docs.google.com/document/d/1BctJRNczyWVht8AtVRbD7zDLJRYHFCFsb2X3w82mjD4/edit.

Web Bluetooth has a significantly higher signup rate than the other origin trials, but we haven't done enough origin trials to know how this predicts use after we ship.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No: We do not yet support Windows or Android WebView. The Windows 10 implementation is possible using WinRT functions but isn't finished yet. WebView needs a new API to let the embedding native app control access to the Bluetooth system. We'll implement at least Windows before significantly expanding the API, but since the primary use case is for mobile users, we didn't want to wait on Windows before giving the API to Android users.

https://github.com/WebBluetoothCG/web-bluetooth/blob/master/implementation-status.md#notes describes the version constraints on Windows, Mac, Linux, and Android. The most significant constraint is that only Android M and later is supported, in order to ask for the needed permission inline instead of during a Chrome update.

Demo link

This YouTube video controlling a micro:bit demonstrates the feature well. To try yourself requires a device to connect to. See the Web Bluetooth samples, demos, and code-labs for interactive demos, and the community for a collection of recent demos that have been shared.

Debuggability

The API produces exceptions with descriptive error messages, and we're working on a chrome://bluetooth-internals page that'll expose Bluetooth logs, which help with debugging Web Bluetooth problems.

Interoperability and Compatibility Risk

We believe Web Bluetooth has a high level of interoperability risk, but also significantly moves the web forward.

Mozilla: Servo is implementing.

Edge: Under consideration / Low.

Safari: No public signals

We believe that Edge and Mozilla have prioritized other features above Bluetooth based on their perceptions of developer needs. Mozilla has also expressed some security concerns that we've responded to. We hope that shipping in Chrome will demonstrate enough developer enthusiasm to raise their prioritization, and that it will demonstrate that the feature is secure enough to ship.

There's a chance other browsers will demand API changes at a later date, which will break compatibility with our users. We think this risk is tolerable because we've already passed the API by other spec writers and have made the changes they suggested. When there were changes, it's been possible to migrate to them backward-compatibly.

OWP launch tracking bug

https://crbug.com/581740

Entry on the feature dashboard

https://www.chromestatus.com/features/5264933985976320

[Kenneth Rohde Christiansen]

Just wanted to say that this makes me and many others that I know, very excited!

Kenneth

--
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+...@chromium.org.

[Chris Harrelson]

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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.

[Rick Byers]

LGTM2

I agree the interop risk is high, but that this adds a capability which may prove (over time) to be important to the mobile web and so worth some risk.  And it's clear there's a team committed to long-term investments in standardization and interoperability here. 

One thing that can help reduce the interop risk (make it easier for other interoperable implementations to follow) is an interop test suite.  I know much of the functionality can't currently be tested is a standard automated way (we're working towards fixing this).  But has anyone explored some basic API-shape tests, or some simple manual tests, or whatever else Servo folks say would help them with their implementation?

The table here is a little worrying from a platform predictability perspective.  To what extent is each row in the table easily feature-detectable?  Hopefully developers should never need to hard-code things based on this table, relying only on simple feature detection.

On Fri, Oct 14, 2016 at 7:00 PM, Chris Harrelson <chri...@chromium.org> wrote:

LGTM1

[Jeffrey Yasskin]

On Sat, Oct 15, 2016 at 7:12 AM, Rick Byers <rby...@chromium.org> wrote:

LGTM2

I agree the interop risk is high, but that this adds a capability which may prove (over time) to be important to the mobile web and so worth some risk.  And it's clear there's a team committed to long-term investments in standardization and interoperability here. 

One thing that can help reduce the interop risk (make it easier for other interoperable implementations to follow) is an interop test suite.  I know much of the functionality can't currently be tested is a standard automated way (we're working towards fixing this).  But has anyone explored some basic API-shape tests, or some simple manual tests, or whatever else Servo folks say would help them with their implementation?

I forgot to mention this: Servo is using our layout tests, and discovered WebBluetoothCG/web-bluetooth#296 using them. Clearly that's not as good as upstreamed WPT tests, which we're scheduled to work on starting after the M56 branch point, but it seems to be effective.

 

The table here is a little worrying from a platform predictability perspective.  To what extent is each row in the table easily feature-detectable?  Hopefully developers should never need to hard-code things based on this table, relying only on simple feature detection.

Most things in the table are feature-detectable by checking whether the function or attribute is undefined. The ones that aren't are:

• The elements under Discovery, because they're dictionary entries. Do you have any suggestions?
• The permissions.* items reject their promise if they get an unknown permission name.
• Persistent Device IDs aren't directly detectable, but they'll come along with permissions.query().
• Stop GATT Notifications is just silent when it's not implemented. This could waste power in the remote device.
  
• Event bubbling isn't detectable, but if you'd want to detect it, you can just treat it as not present.
• "{start,stop}Notifications returns this" is the same
  
• "Invalidate objects upon disconnect" is also similar: you just treat it as implemented in order to be compatible.
• "TypeError for bad UUIDs" was a change in the type of an exception: folks probably don't need to detect it.

Jeffrey

On Fri, Oct 14, 2016 at 7:00 PM, Chris Harrelson <chri...@chromium.org> wrote:

LGTM1

[TAMURA, Kent]

LGTM3 as an API owner.

Blink>Bluetooth already has 120 issues. Is the implementation stable enough?

--

TAMURA Kent
Software Engineer, Google

[Rick Byers]

On Sat, Oct 15, 2016 at 12:52 PM, Jeffrey Yasskin <jyas...@google.com> wrote:

On Sat, Oct 15, 2016 at 7:12 AM, Rick Byers <rby...@chromium.org> wrote:

LGTM2

I agree the interop risk is high, but that this adds a capability which may prove (over time) to be important to the mobile web and so worth some risk.  And it's clear there's a team committed to long-term investments in standardization and interoperability here. 

One thing that can help reduce the interop risk (make it easier for other interoperable implementations to follow) is an interop test suite.  I know much of the functionality can't currently be tested is a standard automated way (we're working towards fixing this).  But has anyone explored some basic API-shape tests, or some simple manual tests, or whatever else Servo folks say would help them with their implementation?

I forgot to mention this: Servo is using our layout tests, and discovered WebBluetoothCG/web-bluetooth#296 using them. Clearly that's not as good as upstreamed WPT tests, which we're scheduled to work on starting after the M56 branch point, but it seems to be effective.

Excellent!  Supporting other implementors in whatever way works for them is what matters. 

The table here is a little worrying from a platform predictability perspective.  To what extent is each row in the table easily feature-detectable?  Hopefully developers should never need to hard-code things based on this table, relying only on simple feature detection.

Most things in the table are feature-detectable by checking whether the function or attribute is undefined. The ones that aren't are:

• The elements under Discovery, because they're dictionary entries. Do you have any suggestions?

Dictionary members are feature detectable, it's just a little awkward, not well known and hard for many developers to understand.  You could recommend that existing pattern and add more motivation to that webidl issue if you find (as I did) your developers don't like it.

• The permissions.* items reject their promise if they get an unknown permission name.

Seems like a potential issue to me - I filed this permissions API spec issue to discuss it further.

• Persistent Device IDs aren't directly detectable, but they'll come along with permissions.query(). 

• Stop GATT Notifications is just silent when it's not implemented. This could waste power in the remote device.
  
• Event bubbling isn't detectable, but if you'd want to detect it, you can just treat it as not present.

• "{start,stop}Notifications returns this" is the same
  
• "Invalidate objects upon disconnect" is also similar: you just treat it as implemented in order to be compatible.
• "TypeError for bad UUIDs" was a change in the type of an exception: folks probably don't need to detect it.

Thanks for the details, sounds probably OK.  But please keep your eyes out for scenarios where developers are tempted to hard-code checks like "is this Android" or "is this Chrome >55".  It's easy to under-prioritize good solutions for such use cases until it's too late :-)

[Vincent Scheib]

We are shipping a core subset of the specification (as described earlier), and have issues tracking both the continued feature development, refactoring work, and a a few known defects (about 13) that we do not consider ship blocking.

[Joe Medley]

Guys,

Which version are you planning to ship this in? I have a note that suggests M57, but that was from way before the Intent to Ship.

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Jeffrey Yasskin]

In the Intent to Ship's summary I said M56.

[matt...@gmail.com]

This broke a great many peoples bluetooth audio functionality, mine included. There wasn't exactly a lot of user outreach on this and it was hard for even a technically minded guy to track down exactly where things broke - then only because I decided to have one more shot at finding answers before opening my laptop, unscrewing the screw that only crazy people unscrew, and force installing linux. I saw a whooollle lot of less tech savvy complaints along the way that I'm sure no google employee ever set eyes on.

I hope you roll this back until it's stable - or cross implement separate bluetooth headset functionality - I'm gonna have one more screw lose otherwise, and I already have a few. lol

[Jeffrey Yasskin]

Could you file a bug at https://new.crbug.com/ describing exactly what broke, what other reports of breakage you found, why you think it's a result of the Web Bluetooth API launch, and if you managed to fix it, what you did to fix it?

Thanks,

Jeffrey

[Boris Zbarsky]

On 10/13/16 1:06 PM, 'Jeffrey Yasskin' via blink-dev wrote:
> Mozilla: Servo is implementing. <https://szeged.github.io/servo/>

I didn't catch this at the time, but just so we're clear:

1) The feature set of Servo does not represent any commitment by Mozilla
to ship anything in Firefox, nor interest in doing so, nor opinion as to
the quality of the APIs involved.

2) Servo does not have, to my knowledge, any public intent-like process
to notify people that things are being implemented.

3) The people who would be the equivalent of Blink's "API owners" at
Mozilla do not follow the details of Servo development and do not have
control over what gets implemented in Servo (well, except maybe one person).

So you should probably not conclude anything about "Mozilla" from any
information about the servo tree.

-Boris

[matt...@gmail.com]

Thanks Jeffery, will do!

I'm on a chromebook at the moment and I couldn't track down the exact bit of code, so I decided my best bet was to do a search of other users that had the same problem on the google help forum for chromium and date the update that caused it. It may be strictly an HP issue, but I wouldn't quote me on that.

Essentially chromium will detect bluetooth audio devices, connect, then not offer the device as a sound/volume option and disconnect after a short period of time. I've been Ctrl+Shift+I ing that the problem is still there every chromium update, but I honestly suspect no one reads those unless they suddenly spike.

With this being the only bluetooth related feature pushed with the Nov dev channel update and that being when it first popped up it wasn't hard to spot the what when it came to the source of the problem: though the why still boggles me a bit. I'm a hardware guy, strictly copy and paste when it comes to software solutions. 

My "fix" when chromium disabled the ability to prevent laptops from sleeping with the lid closed was to open it, pull a cable, and stick it to the upper lid with a bit of electrical tape in case they ever re-enabled the feature. Hardly elegant, but sometimes that's just how you have to fix front end functionality issues - tape. lol

Somehow tape just isn't working this time, but after testing multiple devices I can say definitively it's not a hardware problem.

Quick FYI: The number one suggestion for fixing unusual problems on the chromebook help forum is to buy a computer with a different OS - if you ever talk to someone in charge of web presence you might want to suggest they hire extra staff strictly to moderate. (I'm avaliable, qualified when it comes to hardware, and suffer a registered disability that has given me enough free time to tool around tracing down the source of weird chromebook problems if that helps at all ;))

Thanks,

Matt

[Vincent Scheib]

BCC:blink-dev

I believe this is a known chrome os audio issue being actively worked on by the Chrome OS team. https://bugs.chromium.org/p/chromium/issues/detail?id=636078

[rei...@chromium.org]

I intend to enable Web Bluetooth for Windows 10 clients in M-70. A shout-out to jdoerrie@ on the WebAuthn team for his hard work building the WinRT-based implementation.