bluetooth: Add FakeBluetooth interface

bluetooth: Add FakeBluetooth interface

Adds the FakeBluetooth interface with a stub function, web-bluetooth-test.js which
acquires a pointer to that interface and calls its method.

Based on https://docs.google.com/document/d/1Nhv_oVDCodd1pEH_jj9k8gF4rPGb_84VYaZ9IG8M_WY/edit#heading=h.kingfw5ed9qq

BUG=569709
Review-Url: https://codereview.chromium.org/2737343003
Cr-Commit-Position: refs/heads/master@{#465416}
Committed: https://chromium.googlesource.com/chromium/src/+/97febb8d5616d0119b0d6897cc8c8eda3f96e96d

[ortuno, 2017-03-13 02:32:02]

Description was changed from

==========
bluetooth: Add FakeBluetooth interface

BUG=569709
==========

to

==========
bluetooth: Add FakeBluetooth interface

Adds the FakeBluetooth interface with a stub function, web-bluetooth-test.js
which
acquires a pointer to that interface and calls its method.

Based on
https://docs.google.com/document/d/1Nhv_oVDCodd1pEH_jj9k8gF4rPGb_84VYaZ9IG8M_...

BUG=569709
==========

[ortuno, 2017-03-13 03:26:37]

The CQ bit was checked by ortuno@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-13 03:26:46]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-13 03:38:54]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-13 03:38:55]

Dry run: Try jobs failed on following builders:
  win_clang on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds/...)

[ortuno, 2017-03-13 03:48:20]

The CQ bit was checked by ortuno@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-13 03:48:36]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-13 04:16:09]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-13 04:16:10]

Dry run: Try jobs failed on following builders:
  win_clang on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds/...)

[ortuno, 2017-04-07 06:00:23]

The CQ bit was checked by ortuno@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-07 06:00:40]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[ortuno, 2017-04-07 06:23:20]

ortuno@chromium.org changed reviewers:
+ scheib@chromium.org

[ortuno, 2017-04-07 06:23:20]

scheib: PTAL. This introduces the FakeBluetooth mojo interfaces, implements in
device/bluetooth/test and calls it from Javascript in a Layout Test.

[commit-bot: I haz the power, 2017-04-07 07:38:47]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-07 07:38:48]

Dry run: This issue passed the CQ dry run.

[scheib, 2017-04-08 00:59:50]

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/BUILD.gn
File device/bluetooth/BUILD.gn (right):

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/BUILD....
device/bluetooth/BUILD.gn:44: source_set("mojo_test") {
Let's call this "fake_bluetooth" or "fake_bluetooth_impl"?

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/README.md
File device/bluetooth/README.md (right):

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/README...
device/bluetooth/README.md:57: `src/device/bluetooth/test/`.
Link to src/device/bluetooth/public/interfaces/test/README.md

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/public...
File device/bluetooth/public/interfaces/BUILD.gn (right):

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/public...
device/bluetooth/public/interfaces/BUILD.gn:13: mojom("test_interfaces") {
Let's call this "fake_bluetooth"

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/public...
File device/bluetooth/public/interfaces/test/fake_bluetooth.mojom (right):

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/public...
device/bluetooth/public/interfaces/test/fake_bluetooth.mojom:7: // FakeBluetooth
allows its clients to fake the global Bluetooth state.
Let's create a src/device/bluetooth/public/interfaces/test/README.md and as
important elements of the design are implemented add the design details to it.
It may remain very small, but READMEs are good.

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/test/f...
File device/bluetooth/test/fake_bluetooth.h (right):

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/test/f...
device/bluetooth/test/fake_bluetooth.h:13: // Implementation of FakeBluetooth in
Now that bluetooth/test has a few parts in it, let's explain them with a
README.md

bluetooth test: a test fixture for validating the implementation of
device/bluetooth

mock files: to enable clients to test themselves with mock versions of
device/bluetooth

fake bluetooth: enable clients to test themselves over a mojo interfaces,
implemented by using the mock files.

https://codereview.chromium.org/2737343003/diff/60001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/resources/web-bluetooth-test.js (right):

https://codereview.chromium.org/2737343003/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/resources/web-bluetooth-test.js:15:
'mojo/public/js/bindings',
Maybe OK, but we don't seem to use mojo_.bindings anywhere, so is it needed?

https://codereview.chromium.org/2737343003/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/resources/web-bluetooth-test.js:28: class
FakeBluetooth {
The FakeBluetooth class implements the specified fake bluetooth IDL in JS, using
the getFakeBluetooth above which gets the mojo interface connecting to our
implementation. The term FakeBluetooth is being used too much without describing
which layer it refers to.

One solution would be to not make a "class FakeBluetooth", since I don't believe
we ever need it to be a class nor to be named.

instead just:
navigator.bluetooth.test = {
  setLEAvailability: (available) => {
     ...
  }
}

[ortuno, 2017-04-10 01:47:49]

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/BUILD.gn
File device/bluetooth/BUILD.gn (right):

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/BUILD....
device/bluetooth/BUILD.gn:44: source_set("mojo_test") {
On 2017/04/08 at 00:59:50, scheib wrote:
> Let's call this "fake_bluetooth" or "fake_bluetooth_impl"?

Went with fake_bluetooth

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/README.md
File device/bluetooth/README.md (right):

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/README...
device/bluetooth/README.md:57: `src/device/bluetooth/test/`.
On 2017/04/08 at 00:59:50, scheib wrote:
> Link to src/device/bluetooth/public/interfaces/test/README.md

See reply in fake_bluetooth.mojom

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/public...
File device/bluetooth/public/interfaces/BUILD.gn (right):

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/public...
device/bluetooth/public/interfaces/BUILD.gn:13: mojom("test_interfaces") {
On 2017/04/08 at 00:59:50, scheib wrote:
> Let's call this "fake_bluetooth"

To avoid naming both the interface and the component "fake_bluetooth", I went
with fake_bluetooth_interfaces.

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/public...
File device/bluetooth/public/interfaces/test/fake_bluetooth.mojom (right):

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/public...
device/bluetooth/public/interfaces/test/fake_bluetooth.mojom:7: // FakeBluetooth
allows its clients to fake the global Bluetooth state.
On 2017/04/08 at 00:59:50, scheib wrote:
> Let's create a src/device/bluetooth/public/interfaces/test/README.md and as
important elements of the design are implemented add the design details to it.
It may remain very small, but READMEs are good.

I really dislike the idea of a small README because chances are we are going to
forget about it and its going to rot very easily. Furthermore I don't think a
README for this might be worth it since it's pretty much just throwaway code.

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/test/f...
File device/bluetooth/test/fake_bluetooth.h (right):

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/test/f...
device/bluetooth/test/fake_bluetooth.h:13: // Implementation of FakeBluetooth in
On 2017/04/08 at 00:59:50, scheib wrote:
> Now that bluetooth/test has a few parts in it, let's explain them with a
README.md
> 
> bluetooth test: a test fixture for validating the implementation of
device/bluetooth
> 
> mock files: to enable clients to test themselves with mock versions of
device/bluetooth
> 
> fake bluetooth: enable clients to test themselves over a mojo interfaces,
implemented by using the mock files.

We already go into a lot of detail about the different parts of the folder in
device/bluetooth/README. Should I move that to device/bluetooth/test/README.md?

https://codereview.chromium.org/2737343003/diff/60001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/resources/web-bluetooth-test.js (right):

https://codereview.chromium.org/2737343003/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/resources/web-bluetooth-test.js:15:
'mojo/public/js/bindings',
On 2017/04/08 at 00:59:50, scheib wrote:
> Maybe OK, but we don't seem to use mojo_.bindings anywhere, so is it needed?

I tried to remove it and mojo_.FakeBluetooth.FakeBluetooth became undefined. I
was thinking about adding a comment but then I figured that we shouldn't be
documenting Mojo in our code.

https://codereview.chromium.org/2737343003/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/resources/web-bluetooth-test.js:28: class
FakeBluetooth {
On 2017/04/08 at 00:59:50, scheib wrote:
> The FakeBluetooth class implements the specified fake bluetooth IDL in JS,
using the getFakeBluetooth above which gets the mojo interface connecting to our
implementation. The term FakeBluetooth is being used too much without describing
which layer it refers to.
> 
> One solution would be to not make a "class FakeBluetooth", since I don't
believe we ever need it to be a class nor to be named.
> 
> instead just:
> navigator.bluetooth.test = {
>   setLEAvailability: (available) => {
>      ...
>   }
> }

I feel as if I were implementing OO features using typedef, structs, and
function pointers in C++. I refactored the code a bit to make it more obvious
what each layer means. A small downside of using an object would be that our
polyfill becomes less accurate i.e. "console.log(navigator.bluetooth.test)"
would no longer print FakeBluetooth. Not that it matters that much given the
nature of the class' users.

[ortuno, 2017-04-10 01:48:11]

The CQ bit was checked by ortuno@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-10 01:48:22]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-10 03:17:39]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-10 03:17:40]

Dry run: This issue passed the CQ dry run.

[scheib, 2017-04-10 21:52:32]

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/public...
File device/bluetooth/public/interfaces/test/fake_bluetooth.mojom (right):

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/public...
device/bluetooth/public/interfaces/test/fake_bluetooth.mojom:7: // FakeBluetooth
allows its clients to fake the global Bluetooth state.
On 2017/04/10 01:47:49, ortuno wrote:
> On 2017/04/08 at 00:59:50, scheib wrote:
> > Let's create a src/device/bluetooth/public/interfaces/test/README.md and as
> important elements of the design are implemented add the design details to it.
> It may remain very small, but READMEs are good.
> 
> I really dislike the idea of a small README because chances are we are going
to
> forget about it and its going to rot very easily. Furthermore I don't think a
> README for this might be worth it since it's pretty much just throwaway code.

I'd like to see:
a) Relevant design documentation that lives in the code. Here or up at
device/bluetooth is fine. Yes, docs can rot -- so lets try to not have that
happen. By including in code we're more likely to keep them fresh vs a one-off
external design doc.

b) People be able to discover the docs. If I come to a public/interfaces folder
I expect those interfaces to be described at a high level so that client code
can be understood. Docs inline here, pointing to a device/bluetooth doc, or
adjacent in a READEME.md would all satisfy that.

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/test/f...
File device/bluetooth/test/fake_bluetooth.h (right):

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/test/f...
device/bluetooth/test/fake_bluetooth.h:13: // Implementation of FakeBluetooth in
On 2017/04/10 01:47:49, ortuno wrote:
> On 2017/04/08 at 00:59:50, scheib wrote:
> > Now that bluetooth/test has a few parts in it, let's explain them with a
> README.md
> > 
> > bluetooth test: a test fixture for validating the implementation of
> device/bluetooth
> > 
> > mock files: to enable clients to test themselves with mock versions of
> device/bluetooth
> > 
> > fake bluetooth: enable clients to test themselves over a mojo interfaces,
> implemented by using the mock files.
> 
> We already go into a lot of detail about the different parts of the folder in
> device/bluetooth/README. Should I move that to
device/bluetooth/test/README.md?

At this point I think there's enough test specific details that it makes sense
to document it in a test directory README.md and reference it from
device/bluetooth. But, I care more that we describe it in either vs specifically
which one.

https://codereview.chromium.org/2737343003/diff/80001/device/bluetooth/README.md
File device/bluetooth/README.md (right):

https://codereview.chromium.org/2737343003/diff/80001/device/bluetooth/README...
device/bluetooth/README.md:57: `src/device/bluetooth/test/`. *This interface
will be removed once a Bluetooth
'will be removed' is hard to say... ;) 'should' or 'may' is better. Perhaps
explain why: 

"""
This interface may be removed when a Bluetooth Mojo Service is introduced.
Testing code would implement the service as needed for tests.
"""

However, I also wonder how likely this is. This interface is a reusable test
interface that is likely to be pretty convenient to use. If multiple clients
need to test, it would save them effort vs each one creating a fake mojo service
impl, right?

[ortuno, 2017-04-12 05:49:09]

Thanks!

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/README.md
File device/bluetooth/README.md (right):

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/README...
device/bluetooth/README.md:57: `src/device/bluetooth/test/`.
On 2017/04/10 at 01:47:49, ortuno wrote:
> On 2017/04/08 at 00:59:50, scheib wrote:
> > Link to src/device/bluetooth/public/interfaces/test/README.md
> 
> See reply in fake_bluetooth.mojom

Done.

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/public...
File device/bluetooth/public/interfaces/test/fake_bluetooth.mojom (right):

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/public...
device/bluetooth/public/interfaces/test/fake_bluetooth.mojom:7: // FakeBluetooth
allows its clients to fake the global Bluetooth state.
On 2017/04/10 at 21:52:31, scheib wrote:
> On 2017/04/10 01:47:49, ortuno wrote:
> > On 2017/04/08 at 00:59:50, scheib wrote:
> > > Let's create a src/device/bluetooth/public/interfaces/test/README.md and
as
> > important elements of the design are implemented add the design details to
it.
> > It may remain very small, but READMEs are good.
> > 
> > I really dislike the idea of a small README because chances are we are going
to
> > forget about it and its going to rot very easily. Furthermore I don't think
a
> > README for this might be worth it since it's pretty much just throwaway
code.
> 
> I'd like to see:
> a) Relevant design documentation that lives in the code. Here or up at
device/bluetooth is fine. Yes, docs can rot -- so lets try to not have that
happen. By including in code we're more likely to keep them fresh vs a one-off
external design doc.
> 
> b) People be able to discover the docs. If I come to a public/interfaces
folder I expect those interfaces to be described at a high level so that client
code can be understood. Docs inline here, pointing to a device/bluetooth doc, or
adjacent in a READEME.md would all satisfy that.

OK. I added a README to bluetooth/public/interfaces/test that points to
fake_bluetooth.mojom for more information about the interface and
device/bluetooth/test/README.md for more information about the implementation.
Do you think that's OK? I tried to decouple the implementation details from the
interface given that the implementation details are more likely to change.

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/test/f...
File device/bluetooth/test/fake_bluetooth.h (right):

https://codereview.chromium.org/2737343003/diff/60001/device/bluetooth/test/f...
device/bluetooth/test/fake_bluetooth.h:13: // Implementation of FakeBluetooth in
On 2017/04/10 at 21:52:31, scheib wrote:
> On 2017/04/10 01:47:49, ortuno wrote:
> > On 2017/04/08 at 00:59:50, scheib wrote:
> > > Now that bluetooth/test has a few parts in it, let's explain them with a
> > README.md
> > > 
> > > bluetooth test: a test fixture for validating the implementation of
> > device/bluetooth
> > > 
> > > mock files: to enable clients to test themselves with mock versions of
> > device/bluetooth
> > > 
> > > fake bluetooth: enable clients to test themselves over a mojo interfaces,
> > implemented by using the mock files.
> > 
> > We already go into a lot of detail about the different parts of the folder
in
> > device/bluetooth/README. Should I move that to
device/bluetooth/test/README.md?
> 
> At this point I think there's enough test specific details that it makes sense
to document it in a test directory README.md and reference it from
device/bluetooth. But, I care more that we describe it in either vs specifically
which one.

Moved all the testing bits to test/README.md

https://codereview.chromium.org/2737343003/diff/80001/device/bluetooth/README.md
File device/bluetooth/README.md (right):

https://codereview.chromium.org/2737343003/diff/80001/device/bluetooth/README...
device/bluetooth/README.md:57: `src/device/bluetooth/test/`. *This interface
will be removed once a Bluetooth
On 2017/04/10 at 21:52:31, scheib wrote:
> 'will be removed' is hard to say... ;) 'should' or 'may' is better. Perhaps
explain why: 
> 
> """
> This interface may be removed when a Bluetooth Mojo Service is introduced.
Testing code would implement the service as needed for tests.
> """
> 

Done. I added that we'll remove it if Web Bluetooth is the only client.

> However, I also wonder how likely this is. This interface is a reusable test
interface that is likely to be pretty convenient to use. If multiple clients
need to test, it would save them effort vs each one creating a fake mojo service
impl, right?

I think it will depend on the approach we take when we add the Bluetooth
service. But based on the push back against refactoring clients to use the mojo
service directly and insistence on just using the current interface (T_T) my
guess is that we won't need this.

[scheib, 2017-04-12 18:56:47]

Thanks, lgtm with a doc request; and nits about typo code duplication.

https://codereview.chromium.org/2737343003/diff/80001/device/bluetooth/README.md
File device/bluetooth/README.md (right):

https://codereview.chromium.org/2737343003/diff/80001/device/bluetooth/README...
device/bluetooth/README.md:104: ## Android
I don't think this Android heading should be moved. It primarily is discussing
the architecture of the C++/Java objects and ownership. It also explains how
testing is done -- but that's more of a sub-point of the overall "Hey, Android
is weird because C++/Java". The testing bits could stay here (what I'd do), or
be edited out and migrated to the test directory.

https://codereview.chromium.org/2737343003/diff/100001/device/bluetooth/BUILD.gn
File device/bluetooth/BUILD.gn (right):

https://codereview.chromium.org/2737343003/diff/100001/device/bluetooth/BUILD...
device/bluetooth/BUILD.gn:57: source_set("fake_bluetooth") {
There's now a duplicate source_set fake_bluetooth

https://codereview.chromium.org/2737343003/diff/100001/device/bluetooth/publi...
File device/bluetooth/public/interfaces/BUILD.gn (right):

https://codereview.chromium.org/2737343003/diff/100001/device/bluetooth/publi...
device/bluetooth/public/interfaces/BUILD.gn:19:
mojom("fake_bluetooth_interfaces") {
duplicate definition.

[ortuno, 2017-04-13 01:12:47]

Could you take a quick look again. I changed SetLEAvailability to SetLESupported
since we don't yet check if LE is available in our code, added docs to the
polyfill so that writing the test spec is easier later, and moved
web-bluetooth-test.js to resources/bluetooth/

https://codereview.chromium.org/2737343003/diff/80001/device/bluetooth/README.md
File device/bluetooth/README.md (right):

https://codereview.chromium.org/2737343003/diff/80001/device/bluetooth/README...
device/bluetooth/README.md:104: ## Android
On 2017/04/12 at 18:56:46, scheib wrote:
> I don't think this Android heading should be moved. It primarily is discussing
the architecture of the C++/Java objects and ownership. It also explains how
testing is done -- but that's more of a sub-point of the overall "Hey, Android
is weird because C++/Java". The testing bits could stay here (what I'd do), or
be edited out and migrated to the test directory.

Done.

https://codereview.chromium.org/2737343003/diff/100001/device/bluetooth/BUILD.gn
File device/bluetooth/BUILD.gn (right):

https://codereview.chromium.org/2737343003/diff/100001/device/bluetooth/BUILD...
device/bluetooth/BUILD.gn:57: source_set("fake_bluetooth") {
On 2017/04/12 at 18:56:47, scheib wrote:
> There's now a duplicate source_set fake_bluetooth

wat... I guess "git cl patch" messed up at some point? Thanks for noticing!
Done.

https://codereview.chromium.org/2737343003/diff/100001/device/bluetooth/publi...
File device/bluetooth/public/interfaces/BUILD.gn (right):

https://codereview.chromium.org/2737343003/diff/100001/device/bluetooth/publi...
device/bluetooth/public/interfaces/BUILD.gn:19:
mojom("fake_bluetooth_interfaces") {
On 2017/04/12 at 18:56:47, scheib wrote:
> duplicate definition.

Done.

[ortuno, 2017-04-13 01:12:51]

The CQ bit was checked by ortuno@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-13 01:13:44]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-13 02:56:03]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-13 02:56:04]

Dry run: This issue passed the CQ dry run.

[scheib, 2017-04-13 05:00:56]

lgtm

[ortuno, 2017-04-18 00:57:36]

ortuno@chromium.org changed reviewers:
+ dcheng@chromium.org, peter@chromium.org

[ortuno, 2017-04-18 00:57:37]

dcheng: PTAL at .mojom changes and manifest changes.
peter: PTAL at content/shell changes.

[dcheng, 2017-04-18 01:00:52]

ipc lgtm

[Peter Beverloo, 2017-04-18 17:24:11]

//content/shell/ lgtm

[ortuno, 2017-04-18 21:20:33]

The CQ bit was checked by ortuno@chromium.org

[commit-bot: I haz the power, 2017-04-18 21:21:02]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-18 23:06:43]

CQ is committing da patch.

Bot data: {"patchset_id": 160001, "attempt_start_ts": 1492550433104760,
"parent_rev": "7058e5de9250916cae608b03e8e44873cac4e853", "commit_rev":
"97febb8d5616d0119b0d6897cc8c8eda3f96e96d"}

[commit-bot: I haz the power, 2017-04-18 23:07:12]

Description was changed from

==========
bluetooth: Add FakeBluetooth interface

Adds the FakeBluetooth interface with a stub function, web-bluetooth-test.js
which
acquires a pointer to that interface and calls its method.

Based on
https://docs.google.com/document/d/1Nhv_oVDCodd1pEH_jj9k8gF4rPGb_84VYaZ9IG8M_...

BUG=569709
==========

to

==========
bluetooth: Add FakeBluetooth interface

Adds the FakeBluetooth interface with a stub function, web-bluetooth-test.js
which
acquires a pointer to that interface and calls its method.

Based on
https://docs.google.com/document/d/1Nhv_oVDCodd1pEH_jj9k8gF4rPGb_84VYaZ9IG8M_...

BUG=569709

Review-Url: https://codereview.chromium.org/2737343003
Cr-Commit-Position: refs/heads/master@{#465416}
Committed:
https://chromium.googlesource.com/chromium/src/+/97febb8d5616d0119b0d6897cc8c...
==========

[commit-bot: I haz the power, 2017-04-18 23:07:13]

Committed patchset #9 (id:160001) as
https://chromium.googlesource.com/chromium/src/+/97febb8d5616d0119b0d6897cc8c...