Move chrome.bluetoothLowEnergy out of //chrome.

Move chrome.bluetoothLowEnergy out of //chrome.

This CL moves the Bluetooth Low Energy API out of //chrome and into
//extensions. This will allow us to use this API from AppShell.

This CL also adds the Kiosk Delegate. On Chrome, this delegate will mostly
have stubbed functionality but the delegate does need to exist on all
platforms. This is because AppShell is not restricted only to Chrome OS so
the API will need to be compiled for multiple platforms, whether it is
compiling under a Chrome build or an AppShell build.

Moving the tests will be fairly complicated due to various dependencies
on InProcBrowserTest and ExtensionApiTest. Hence I'll send out a separate
follow on CL to move the tests.

[email protected], [email protected]
BUG=650835
Committed: https://crrev.com/c8e6edea4ad306b0b0bb26ebcb67bb8a4cb91746
Cr-Commit-Position: refs/heads/master@{#421700}

[xiyuan, 2016-09-27 23:07:00]

LGTM but please wait for Devlin

[asargent_no_longer_on_chrome, 2016-09-28 19:58:14]

[email protected] changed reviewers:
+ [email protected]

[asargent_no_longer_on_chrome, 2016-09-28 19:58:15]

https://codereview.chromium.org/2370373002/diff/1/chrome/browser/chromeos/app...
File chrome/browser/chromeos/app_mode/chrome_kiosk_delegate.cc (right):

https://codereview.chromium.org/2370373002/diff/1/chrome/browser/chromeos/app...
chrome/browser/chromeos/app_mode/chrome_kiosk_delegate.cc:24: #endif
Will all the eventual methods here be of the form:

#if defined(OS_CHROMEOS)
  // real code
#else
  return <some sentinel value>;
#endif

?

If so, maybe it would make more sense to use gn to have two different .cc files,
one of which is for non-chromeos and one which is for chromeos.

https://codereview.chromium.org/2370373002/diff/1/extensions/browser/api/exte...
File extensions/browser/api/extensions_api_client.h (right):

https://codereview.chromium.org/2370373002/diff/1/extensions/browser/api/exte...
extensions/browser/api/extensions_api_client.h:132: virtual KioskDelegate*
GetKioskDelegate();
Most of the rest of these functions are named Create* and return std::unique_ptr
which gets stored somewhere, often in a BrowserContextKeyedAPI member variable.
Can this follow that same pattern?

Or does this perhaps belong in ExtensionsBrowserClient, ExtensionSystem, or as
its own KeyedService?

https://codereview.chromium.org/2370373002/diff/1/extensions/browser/kiosk/ki...
File extensions/browser/kiosk/kiosk_delegate.h (right):

https://codereview.chromium.org/2370373002/diff/1/extensions/browser/kiosk/ki...
extensions/browser/kiosk/kiosk_delegate.h:14: // a delegate but till then, this
is class is mostly a wrapper to it.
typo: "this is class" -> "this class"

[Rahul Chaturvedi, 2016-09-28 20:26:47]

https://codereview.chromium.org/2370373002/diff/1/chrome/browser/chromeos/app...
File chrome/browser/chromeos/app_mode/chrome_kiosk_delegate.cc (right):

https://codereview.chromium.org/2370373002/diff/1/chrome/browser/chromeos/app...
chrome/browser/chromeos/app_mode/chrome_kiosk_delegate.cc:24: #endif
On 2016/09/28 19:58:15, Antony Sargent wrote:
> Will all the eventual methods here be of the form:
> 
> #if defined(OS_CHROMEOS)
>   // real code
> #else
>   return <some sentinel value>;
> #endif
> 
> ?
> 
> If so, maybe it would make more sense to use gn to have two different .cc
files,
> one of which is for non-chromeos and one which is for chromeos. 
> 

This also should not be in the //c/b/chromeos/... tree, since it will never get
compiled on other OSes. Moved to //c/b/extensions and split the file into a
_chromeos.cc and .cc.

Done.

https://codereview.chromium.org/2370373002/diff/1/extensions/browser/api/exte...
File extensions/browser/api/extensions_api_client.h (right):

https://codereview.chromium.org/2370373002/diff/1/extensions/browser/api/exte...
extensions/browser/api/extensions_api_client.h:132: virtual KioskDelegate*
GetKioskDelegate();
On 2016/09/28 19:58:15, Antony Sargent wrote:
> Most of the rest of these functions are named Create* and return
std::unique_ptr
> which gets stored somewhere, often in a BrowserContextKeyedAPI member
variable.
> Can this follow that same pattern?
> 
> Or does this perhaps belong in ExtensionsBrowserClient, ExtensionSystem, or as
> its own KeyedService?

So the difference is that the rest of the functions need their delegates to be
context keyed. So we create a new delegate every time they ask, and they save it
to their browser context keyed API state.

This delegate is actually global, hence which is why we don't really need to
create a different delegates but need to create one just once. Which is why it
makes sense to have one global instance per extension client and return it to
anyone who needs it.

Ideally, we probably should have had all of these as
GetXXXDelegate(content::BrowserContext) calls with us managing the storage to
the context keyed state, but that may be too much refactoring to do at this
point.

https://codereview.chromium.org/2370373002/diff/1/extensions/browser/kiosk/ki...
File extensions/browser/kiosk/kiosk_delegate.h (right):

https://codereview.chromium.org/2370373002/diff/1/extensions/browser/kiosk/ki...
extensions/browser/kiosk/kiosk_delegate.h:14: // a delegate but till then, this
is class is mostly a wrapper to it.
On 2016/09/28 19:58:15, Antony Sargent wrote:
> typo: "this is class" -> "this class"

Done.

[asargent_no_longer_on_chrome, 2016-09-28 20:45:19]

https://codereview.chromium.org/2370373002/diff/1/extensions/browser/api/exte...
File extensions/browser/api/extensions_api_client.h (right):

https://codereview.chromium.org/2370373002/diff/1/extensions/browser/api/exte...
extensions/browser/api/extensions_api_client.h:132: virtual KioskDelegate*
GetKioskDelegate();
On 2016/09/28 20:26:47, Rahul Chaturvedi wrote:
> On 2016/09/28 19:58:15, Antony Sargent wrote:
> > Most of the rest of these functions are named Create* and return
> std::unique_ptr
> > which gets stored somewhere, often in a BrowserContextKeyedAPI member
> variable.
> > Can this follow that same pattern?
> > 
> > Or does this perhaps belong in ExtensionsBrowserClient, ExtensionSystem, or
as
> > its own KeyedService?
> 
> So the difference is that the rest of the functions need their delegates to be
> context keyed. So we create a new delegate every time they ask, and they save
it
> to their browser context keyed API state.
> 
> This delegate is actually global, hence which is why we don't really need to
> create a different delegates but need to create one just once. Which is why it
> makes sense to have one global instance per extension client and return it to
> anyone who needs it.
> 
> Ideally, we probably should have had all of these as
> GetXXXDelegate(content::BrowserContext) calls with us managing the storage to
> the context keyed state, but that may be too much refactoring to do at this
> point.

Thinking about this some more, does the KioskDelegate have anything to do with a
particular API? The stated purpose of the ExtensionsAPIClient is for an embedder
to "customize its support for API features", and most of the functions here
indeed have something to do with a particular API. The KioskDelegate interface
so far just has IsAutoLaunchedKioskApp, which seems sort of orthogonal to any
particular API. 

Since the KioskDelegate is global and not BrowserContext-dependent, maybe a good
fit would be to put it in ExtensionsClient ("Sets up global state for the
extensions system")? Or possibly just have a static KioskDelegate::Get() method?

[Rahul Chaturvedi, 2016-09-28 21:10:29]

https://codereview.chromium.org/2370373002/diff/1/extensions/browser/api/exte...
File extensions/browser/api/extensions_api_client.h (right):

https://codereview.chromium.org/2370373002/diff/1/extensions/browser/api/exte...
extensions/browser/api/extensions_api_client.h:132: virtual KioskDelegate*
GetKioskDelegate();
On 2016/09/28 20:45:19, Antony Sargent wrote:
> On 2016/09/28 20:26:47, Rahul Chaturvedi wrote:
> > On 2016/09/28 19:58:15, Antony Sargent wrote:
> > > Most of the rest of these functions are named Create* and return
> > std::unique_ptr
> > > which gets stored somewhere, often in a BrowserContextKeyedAPI member
> > variable.
> > > Can this follow that same pattern?
> > > 
> > > Or does this perhaps belong in ExtensionsBrowserClient, ExtensionSystem,
or
> as
> > > its own KeyedService?
> > 
> > So the difference is that the rest of the functions need their delegates to
be
> > context keyed. So we create a new delegate every time they ask, and they
save
> it
> > to their browser context keyed API state.
> > 
> > This delegate is actually global, hence which is why we don't really need to
> > create a different delegates but need to create one just once. Which is why
it
> > makes sense to have one global instance per extension client and return it
to
> > anyone who needs it.
> > 
> > Ideally, we probably should have had all of these as
> > GetXXXDelegate(content::BrowserContext) calls with us managing the storage
to
> > the context keyed state, but that may be too much refactoring to do at this
> > point.
> 
> Thinking about this some more, does the KioskDelegate have anything to do with
a
> particular API? The stated purpose of the ExtensionsAPIClient is for an
embedder
> to "customize its support for API features", and most of the functions here
> indeed have something to do with a particular API. The KioskDelegate interface
> so far just has IsAutoLaunchedKioskApp, which seems sort of orthogonal to any
> particular API. 
> 
> Since the KioskDelegate is global and not BrowserContext-dependent, maybe a
good
> fit would be to put it in ExtensionsClient ("Sets up global state for the
> extensions system")? Or possibly just have a static KioskDelegate::Get()
method?
> 
> 
> 
> 

I really don't want to have a global ::Get. This code gets to leverage the
mechanisms in place already for getting the correct [Chrome|Shell] delegate with
using the API|extensions client.

ExtensionsClient does work but it feels a bit wrong. This code may be used by
several APIs but it will still be used to API specific code. It just so happens
that many APIs will need the information it provides.

Looking at all the methods in ExtensionsClient, this seems to fit better with
the ExtensionsApiClient methods.

[asargent_no_longer_on_chrome, 2016-09-28 21:49:42]

https://codereview.chromium.org/2370373002/diff/1/extensions/browser/api/exte...
File extensions/browser/api/extensions_api_client.h (right):

https://codereview.chromium.org/2370373002/diff/1/extensions/browser/api/exte...
extensions/browser/api/extensions_api_client.h:132: virtual KioskDelegate*
GetKioskDelegate();
On 2016/09/28 21:10:29, Rahul Chaturvedi wrote:
> On 2016/09/28 20:45:19, Antony Sargent wrote:
> > On 2016/09/28 20:26:47, Rahul Chaturvedi wrote:
> > > On 2016/09/28 19:58:15, Antony Sargent wrote:
> > > > Most of the rest of these functions are named Create* and return
> > > std::unique_ptr
> > > > which gets stored somewhere, often in a BrowserContextKeyedAPI member
> > > variable.
> > > > Can this follow that same pattern?
> > > > 
> > > > Or does this perhaps belong in ExtensionsBrowserClient, ExtensionSystem,
> or
> > as
> > > > its own KeyedService?
> > > 
> > > So the difference is that the rest of the functions need their delegates
to
> be
> > > context keyed. So we create a new delegate every time they ask, and they
> save
> > it
> > > to their browser context keyed API state.
> > > 
> > > This delegate is actually global, hence which is why we don't really need
to
> > > create a different delegates but need to create one just once. Which is
why
> it
> > > makes sense to have one global instance per extension client and return it
> to
> > > anyone who needs it.
> > > 
> > > Ideally, we probably should have had all of these as
> > > GetXXXDelegate(content::BrowserContext) calls with us managing the storage
> to
> > > the context keyed state, but that may be too much refactoring to do at
this
> > > point.
> > 
> > Thinking about this some more, does the KioskDelegate have anything to do
with
> a
> > particular API? The stated purpose of the ExtensionsAPIClient is for an
> embedder
> > to "customize its support for API features", and most of the functions here
> > indeed have something to do with a particular API. The KioskDelegate
interface
> > so far just has IsAutoLaunchedKioskApp, which seems sort of orthogonal to
any
> > particular API. 
> > 
> > Since the KioskDelegate is global and not BrowserContext-dependent, maybe a
> good
> > fit would be to put it in ExtensionsClient ("Sets up global state for the
> > extensions system")? Or possibly just have a static KioskDelegate::Get()
> method?
> > 
> > 
> > 
> > 
> 
> I really don't want to have a global ::Get. This code gets to leverage the
> mechanisms in place already for getting the correct [Chrome|Shell] delegate
with
> using the API|extensions client.
> 
> ExtensionsClient does work but it feels a bit wrong. This code may be used by
> several APIs but it will still be used to API specific code. It just so
happens
> that many APIs will need the information it provides.
> 
> Looking at all the methods in ExtensionsClient, this seems to fit better with
> the ExtensionsApiClient methods.

I'd still prefer that we put this in ExtensionsClient (or
ExtensionsBrowserClient, if it will eventually need to know about browser
process concepts)- I agree that the rest of the methods in ExtensionsClient are
a little different, but I still think it fits better with the stated purpose of
ExtensionsClient than the stated purpose of ExtensionsAPIClient.

[Rahul Chaturvedi, 2016-09-28 23:00:10]

https://codereview.chromium.org/2370373002/diff/1/extensions/browser/api/exte...
File extensions/browser/api/extensions_api_client.h (right):

https://codereview.chromium.org/2370373002/diff/1/extensions/browser/api/exte...
extensions/browser/api/extensions_api_client.h:132: virtual KioskDelegate*
GetKioskDelegate();
On 2016/09/28 21:49:41, Antony Sargent wrote:
> On 2016/09/28 21:10:29, Rahul Chaturvedi wrote:
> > On 2016/09/28 20:45:19, Antony Sargent wrote:
> > > On 2016/09/28 20:26:47, Rahul Chaturvedi wrote:
> > > > On 2016/09/28 19:58:15, Antony Sargent wrote:
> > > > > Most of the rest of these functions are named Create* and return
> > > > std::unique_ptr
> > > > > which gets stored somewhere, often in a BrowserContextKeyedAPI member
> > > > variable.
> > > > > Can this follow that same pattern?
> > > > > 
> > > > > Or does this perhaps belong in ExtensionsBrowserClient,
ExtensionSystem,
> > or
> > > as
> > > > > its own KeyedService?
> > > > 
> > > > So the difference is that the rest of the functions need their delegates
> to
> > be
> > > > context keyed. So we create a new delegate every time they ask, and they
> > save
> > > it
> > > > to their browser context keyed API state.
> > > > 
> > > > This delegate is actually global, hence which is why we don't really
need
> to
> > > > create a different delegates but need to create one just once. Which is
> why
> > it
> > > > makes sense to have one global instance per extension client and return
it
> > to
> > > > anyone who needs it.
> > > > 
> > > > Ideally, we probably should have had all of these as
> > > > GetXXXDelegate(content::BrowserContext) calls with us managing the
storage
> > to
> > > > the context keyed state, but that may be too much refactoring to do at
> this
> > > > point.
> > > 
> > > Thinking about this some more, does the KioskDelegate have anything to do
> with
> > a
> > > particular API? The stated purpose of the ExtensionsAPIClient is for an
> > embedder
> > > to "customize its support for API features", and most of the functions
here
> > > indeed have something to do with a particular API. The KioskDelegate
> interface
> > > so far just has IsAutoLaunchedKioskApp, which seems sort of orthogonal to
> any
> > > particular API. 
> > > 
> > > Since the KioskDelegate is global and not BrowserContext-dependent, maybe
a
> > good
> > > fit would be to put it in ExtensionsClient ("Sets up global state for the
> > > extensions system")? Or possibly just have a static KioskDelegate::Get()
> > method?
> > > 
> > > 
> > > 
> > > 
> > 
> > I really don't want to have a global ::Get. This code gets to leverage the
> > mechanisms in place already for getting the correct [Chrome|Shell] delegate
> with
> > using the API|extensions client.
> > 
> > ExtensionsClient does work but it feels a bit wrong. This code may be used
by
> > several APIs but it will still be used to API specific code. It just so
> happens
> > that many APIs will need the information it provides.
> > 
> > Looking at all the methods in ExtensionsClient, this seems to fit better
with
> > the ExtensionsApiClient methods.
> 
> I'd still prefer that we put this in ExtensionsClient (or
> ExtensionsBrowserClient, if it will eventually need to know about browser
> process concepts)- I agree that the rest of the methods in ExtensionsClient
are
> a little different, but I still think it fits better with the stated purpose
of
> ExtensionsClient than the stated purpose of ExtensionsAPIClient. 
> 
> 
Moved to ExtensionsBrowserClient (since ExtensionsClient has a dependency issue
with //c/b/chromeos).
Done.

[asargent_no_longer_on_chrome, 2016-09-28 23:03:33]

lgtm

[Rahul Chaturvedi, 2016-09-28 23:04:50]

The CQ bit was checked by [email protected]

[Rahul Chaturvedi, 2016-09-28 23:04:51]

The patchset sent to the CQ was uploaded after l-g-t-m from [email protected]
Link to the patchset: https://codereview.chromium.org/2370373002/#ps40001
(title: ".")

[commit-bot: I haz the power, 2016-09-28 23:05:25]

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, 2016-09-28 23:21:24]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2016-09-28 23:21:25]

Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Rahul Chaturvedi, 2016-09-28 23:27:34]

The CQ bit was checked by [email protected]

[Rahul Chaturvedi, 2016-09-28 23:27:35]

The patchset sent to the CQ was uploaded after l-g-t-m from [email protected],
[email protected]
Link to the patchset: https://codereview.chromium.org/2370373002/#ps60001
(title: "build fix")

[commit-bot: I haz the power, 2016-09-28 23:27:53]

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, 2016-09-29 00:56:58]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-09-29 01:07:36]

Description was changed from

==========
Move chrome.bluetoothLowEnergy out of //chrome.

This CL moves the Bluetooth Low Energy API out of //chrome and into
//extensions. This will allow us to use this API from AppShell.

This CL also adds the Kiosk Delegate. On Chrome, this delegate will mostly
have stubbed functionality but the delegate does need to exist on all
platforms. This is because AppShell is not restricted only to Chrome OS so
the API will need to be compiled for multiple platforms, whether it is
compiling under a Chrome build or an AppShell build.

Moving the tests will be fairly complicated due to various dependencies
on InProcBrowserTest and ExtensionApiTest. Hence I'll send out a separate
follow on CL to move the tests.

[email protected], [email protected]
BUG=650835
==========

to

==========
Move chrome.bluetoothLowEnergy out of //chrome.

This CL moves the Bluetooth Low Energy API out of //chrome and into
//extensions. This will allow us to use this API from AppShell.

This CL also adds the Kiosk Delegate. On Chrome, this delegate will mostly
have stubbed functionality but the delegate does need to exist on all
platforms. This is because AppShell is not restricted only to Chrome OS so
the API will need to be compiled for multiple platforms, whether it is
compiling under a Chrome build or an AppShell build.

Moving the tests will be fairly complicated due to various dependencies
on InProcBrowserTest and ExtensionApiTest. Hence I'll send out a separate
follow on CL to move the tests.

[email protected], [email protected]
BUG=650835

Committed: https://crrev.com/c8e6edea4ad306b0b0bb26ebcb67bb8a4cb91746
Cr-Commit-Position: refs/heads/master@{#421700}
==========

[commit-bot: I haz the power, 2016-09-29 01:07:38]

Patchset 4 (id:??) landed as
https://crrev.com/c8e6edea4ad306b0b0bb26ebcb67bb8a4cb91746
Cr-Commit-Position: refs/heads/master@{#421700}

[trchen, 2016-10-26 00:27:29]

Hello, I'm not sure if it began with this CL, but there is a race in the build,
that

obj/extensions/browser/api/bluetooth_low_energy/bluetooth_low_energy/bluetooth_low_energy_api.o
obj/extensions/browser/api/bluetooth_low_energy/bluetooth_low_energy/bluetooth_low_energy_event_router.o
... and a bunch of related objects ...

will be built before gen/extensions/common/api/bluetooth_low_energy.h getting
generated. I'm not an expert in this area and in GN, could you investigate?
Thanks!

[trchen, 2016-10-26 00:27:55]

Description was changed from

==========
Move chrome.bluetoothLowEnergy out of //chrome.

This CL moves the Bluetooth Low Energy API out of //chrome and into
//extensions. This will allow us to use this API from AppShell.

This CL also adds the Kiosk Delegate. On Chrome, this delegate will mostly
have stubbed functionality but the delegate does need to exist on all
platforms. This is because AppShell is not restricted only to Chrome OS so
the API will need to be compiled for multiple platforms, whether it is
compiling under a Chrome build or an AppShell build.

Moving the tests will be fairly complicated due to various dependencies
on InProcBrowserTest and ExtensionApiTest. Hence I'll send out a separate
follow on CL to move the tests.

[email protected], [email protected]
BUG=650835

Committed: https://crrev.com/c8e6edea4ad306b0b0bb26ebcb67bb8a4cb91746
Cr-Commit-Position: refs/heads/master@{#421700}
==========

to

==========
Move chrome.bluetoothLowEnergy out of //chrome.

This CL moves the Bluetooth Low Energy API out of //chrome and into
//extensions. This will allow us to use this API from AppShell.

This CL also adds the Kiosk Delegate. On Chrome, this delegate will mostly
have stubbed functionality but the delegate does need to exist on all
platforms. This is because AppShell is not restricted only to Chrome OS so
the API will need to be compiled for multiple platforms, whether it is
compiling under a Chrome build or an AppShell build.

Moving the tests will be fairly complicated due to various dependencies
on InProcBrowserTest and ExtensionApiTest. Hence I'll send out a separate
follow on CL to move the tests.

[email protected], [email protected]
BUG=650835

Committed: https://crrev.com/c8e6edea4ad306b0b0bb26ebcb67bb8a4cb91746
Cr-Commit-Position: refs/heads/master@{#421700}
==========

[xiyuan, 2016-10-26 18:37:12]

On 2016/10/26 00:27:29, trchen wrote:
> Hello, I'm not sure if it began with this CL, but there is a race in the
build,
> that
> 
>
obj/extensions/browser/api/bluetooth_low_energy/bluetooth_low_energy/bluetooth_low_energy_api.o
>
obj/extensions/browser/api/bluetooth_low_energy/bluetooth_low_energy/bluetooth_low_energy_event_router.o
> ... and a bunch of related objects ...
> 
> will be built before gen/extensions/common/api/bluetooth_low_energy.h getting
> generated. I'm not an expert in this area and in GN, could you investigate?
> Thanks!

Sounds like we are missing "//extensions/common/api" in deps of
extensions/browser/api/bluetooth_low_energy/BUILD.gn

steel@, could you check?

[Lei Zhang, 2017-08-21 19:29:47]

https://codereview.chromium.org/2370373002/diff/60001/chrome/browser/extensio...
File chrome/browser/extensions/BUILD.gn (right):

https://codereview.chromium.org/2370373002/diff/60001/chrome/browser/extensio...
chrome/browser/extensions/BUILD.gn:914: if (!is_chromeos) {
BTW, seeing how there is an is_chromeos block below, it has an existing else
block that this could have been placed in. I'll do that in a follow up CL.