Implement instant apps infobar.

Implement instant apps infobar.

Has the expected visual treatment, but doesn't currently do anything functionally.
Also no one is currently launching the infobar.

BUG=639497
Committed: https://crrev.com/90230d6b1e2c01b34b9f30f11b82a648dead98ce
Cr-Commit-Position: refs/heads/master@{#414272}

[Maria, 2016-08-19 23:11:35]

mariakhomenko@chromium.org changed reviewers:
+ dfalcantara@chromium.org

[gone, 2016-08-22 17:16:51]

Seems fine to me overall.

lgtm

https://chromiumcodereview.appspot.com/2267463002/diff/20001/components/infob...
File components/infobars/core/infobar_delegate.h (right):

https://chromiumcodereview.appspot.com/2267463002/diff/20001/components/infob...
components/infobars/core/infobar_delegate.h:136:
SUBRESOURCE_FILTER_INFOBAR_DELEGATE_ANDROID = 66,
_ANDROID because this thing is Android-only.

[gone, 2016-08-22 17:17:27]

Could use some screenshots, though.

[Maria, 2016-08-23 05:11:25]

The CQ bit was checked by mariakhomenko@chromium.org

[Maria, 2016-08-23 05:11:29]

The CQ bit was unchecked by mariakhomenko@chromium.org

[Maria, 2016-08-23 05:21:52]

mariakhomenko@chromium.org changed reviewers:
+ isherman@chromium.org, pkasting@chromium.org

[Maria, 2016-08-23 05:21:53]

+ pkasting for components/infobar/.. approval
+ isherman for histograms.xml approval

[Peter Kasting, 2016-08-23 07:59:22]

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/a...
File chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc
(right):

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc:18: const
base::android::ScopedJavaGlobalRef<jobject>& jdata) : data_(jdata) {
Don't expose a public constructor.  Infobar delegate constructors should be
private.

Instead expose a public Create() function that takes an InfoBarService* and any
necessary args, and make that function create the delegate and add it to the
infobar service.  Basically, what Launch() is doing, except drop the first two
(unused) args and move the computation of the InfoBarService* to the caller
side.

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc:20:
java_delegate_.Reset(Java_InstantAppsInfoBarDelegate_create(
Do we really need both a Java infobar and a Java infobar delegate?  Seems like
most Android infobars get by with just the former.

And it seems like usually, when the Java side wants to access the C++ delegate,
the Java infobar has a pointer to the C++ infobar, and from there it can get at
the infobar delegate.  I'm uneasy about having an object that has a direct
pointer to this delegate.

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc:33: //
Message is set in InstantAppInfobar.java
So why are we overriding this method?

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc:53:
base::android::ScopedJavaGlobalRef<jobject>(jdata)));
AndroidDownloadManagerOverwriteInfoBarDelegate just passes this in as a jobject
by value instead of constructing a ScopedJavaGlobalRef here.  The scoped ref
doesn't seem to buy much anyway given that the infobar delegate constructs its
own, so this ref lives only for the life of the function call.  Seems like we
should just nuke it.

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc:54:
infobar_service->AddInfoBar(base::WrapUnique(
Nit: Use MakeUnique() rather than WrapUnique(new()).

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/u...
File chrome/browser/ui/android/infobars/instant_apps_infobar.h (right):

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/u...
chrome/browser/ui/android/infobars/instant_apps_infobar.h:13: class
InstantAppsInfoBar : public ConfirmInfoBar {
Subclassing ConfirmInfoBar seems wrong.  Seems like you should be subclassing
InfoBarAndroid.

[Ilya Sherman, 2016-08-23 19:23:31]

histograms.xml lgtm % a nit:

https://chromiumcodereview.appspot.com/2267463002/diff/40001/tools/metrics/hi...
File tools/metrics/histograms/histograms.xml (right):

https://chromiumcodereview.appspot.com/2267463002/diff/40001/tools/metrics/hi...
tools/metrics/histograms/histograms.xml:82005: +  <int value="67"
label="INSTANT_APPS_INFOBAR_DELEGATE"/>
While you're here, could you please add an entry for
SUBRESOURCE_FILTER_INFOBAR_DELEGATE_ANDROID as well?

[Maria, 2016-08-23 21:30:28]

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/a...
File chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc
(right):

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc:18: const
base::android::ScopedJavaGlobalRef<jobject>& jdata) : data_(jdata) {
On 2016/08/23 07:59:22, Peter Kasting wrote:
> Don't expose a public constructor.  Infobar delegate constructors should be
> private.
> 
> Instead expose a public Create() function that takes an InfoBarService* and
any
> necessary args, and make that function create the delegate and add it to the
> infobar service.  Basically, what Launch() is doing, except drop the first two
> (unused) args and move the computation of the InfoBarService* to the caller
> side.

Done.

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc:20:
java_delegate_.Reset(Java_InstantAppsInfoBarDelegate_create(
On 2016/08/23 07:59:22, Peter Kasting wrote:
> Do we really need both a Java infobar and a Java infobar delegate?  Seems like
> most Android infobars get by with just the former.
> 
> And it seems like usually, when the Java side wants to access the C++
delegate,
> the Java infobar has a pointer to the C++ infobar, and from there it can get
at
> the infobar delegate.  I'm uneasy about having an object that has a direct
> pointer to this delegate.

Many Java infobars actually do have java infobar delegates, see:

AppBannerInofBarDelegateAndroid, DataReductionPromoInfoBarDelegate,
GeneratePassowrdSavedInfoBarDelegate, PermissionUpdateInfoBarDelegate

I view the delegate as the controller for the infobar where the view is the
infobar class itself.

The pointer is needed when making calls from java to native. This CL currently
doesn't do it, but it ostensibly might. I am just putting in the basics for now.
And it seems like the other delegates do this. What's the reason you think
Java-side shouldn't have access to the delegate?

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc:33: //
Message is set in InstantAppInfobar.java
On 2016/08/23 07:59:22, Peter Kasting wrote:
> So why are we overriding this method?

Because ConfirmInfoBar only provides a pure virtual implementation.

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc:53:
base::android::ScopedJavaGlobalRef<jobject>(jdata)));
On 2016/08/23 07:59:22, Peter Kasting wrote:
> AndroidDownloadManagerOverwriteInfoBarDelegate just passes this in as a
jobject
> by value instead of constructing a ScopedJavaGlobalRef here.  The scoped ref
> doesn't seem to buy much anyway given that the infobar delegate constructs its
> own, so this ref lives only for the life of the function call.  Seems like we
> should just nuke it.

No, this data is used by InstantAppsInfoBar::CreateRenderInfoBar(). If we don't
wrap this into ScopedJavaGlobalRef, the java object can be garbage collected in
java heap, but we need to keep it around to pass to the infobar.

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc:54:
infobar_service->AddInfoBar(base::WrapUnique(
On 2016/08/23 07:59:22, Peter Kasting wrote:
> Nit: Use MakeUnique() rather than WrapUnique(new()).

Done.

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/u...
File chrome/browser/ui/android/infobars/instant_apps_infobar.h (right):

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/u...
chrome/browser/ui/android/infobars/instant_apps_infobar.h:13: class
InstantAppsInfoBar : public ConfirmInfoBar {
On 2016/08/23 07:59:22, Peter Kasting wrote:
> Subclassing ConfirmInfoBar seems wrong.  Seems like you should be subclassing
> InfoBarAndroid.

ConfirmInfoBar is a subclass of InfoBarAndroid that sets up some shared
boilerplate for all infobars of this type.

https://chromiumcodereview.appspot.com/2267463002/diff/40001/tools/metrics/hi...
File tools/metrics/histograms/histograms.xml (right):

https://chromiumcodereview.appspot.com/2267463002/diff/40001/tools/metrics/hi...
tools/metrics/histograms/histograms.xml:82005: +  <int value="67"
label="INSTANT_APPS_INFOBAR_DELEGATE"/>
On 2016/08/23 19:23:31, Ilya Sherman wrote:
> While you're here, could you please add an entry for
> SUBRESOURCE_FILTER_INFOBAR_DELEGATE_ANDROID as well?

Done.

[Peter Kasting, 2016-08-23 22:10:58]

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/a...
File chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc
(right):

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc:20:
java_delegate_.Reset(Java_InstantAppsInfoBarDelegate_create(
On 2016/08/23 21:30:27, Maria wrote:
> On 2016/08/23 07:59:22, Peter Kasting wrote:
> > Do we really need both a Java infobar and a Java infobar delegate?  Seems
like
> > most Android infobars get by with just the former.
> > 
> > And it seems like usually, when the Java side wants to access the C++
> delegate,
> > the Java infobar has a pointer to the C++ infobar, and from there it can get
> at
> > the infobar delegate.  I'm uneasy about having an object that has a direct
> > pointer to this delegate.
> 
> Many Java infobars actually do have java infobar delegates, see:
> 
> AppBannerInofBarDelegateAndroid, DataReductionPromoInfoBarDelegate,
> GeneratePassowrdSavedInfoBarDelegate, PermissionUpdateInfoBarDelegate
> 
> I view the delegate as the controller for the infobar where the view is the
> infobar class itself.
> 
> The pointer is needed when making calls from java to native. This CL currently
> doesn't do it, but it ostensibly might. I am just putting in the basics for
now.

Are you sure it will need this in the future?  If not, don't add it until you
know you need it.

> And it seems like the other delegates do this. What's the reason you think
> Java-side shouldn't have access to the delegate?

You can always get at the infobar delegate from the infobar, but not the other
way around.  And it seems like the Java side should have a pointer to the
infobar anyway.  Isn't that what the Java_InfoBar_setNativeInfoBar call in the
InfoBarAndroid code sets up?

So I would assume you don't also need a direct delegate pointer.

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc:53:
base::android::ScopedJavaGlobalRef<jobject>(jdata)));
On 2016/08/23 21:30:27, Maria wrote:
> On 2016/08/23 07:59:22, Peter Kasting wrote:
> > AndroidDownloadManagerOverwriteInfoBarDelegate just passes this in as a
> jobject
> > by value instead of constructing a ScopedJavaGlobalRef here.  The scoped ref
> > doesn't seem to buy much anyway given that the infobar delegate constructs
its
> > own, so this ref lives only for the life of the function call.  Seems like
we
> > should just nuke it.
> 
> No, this data is used by InstantAppsInfoBar::CreateRenderInfoBar(). If we
don't
> wrap this into ScopedJavaGlobalRef, the java object can be garbage collected
in
> java heap, but we need to keep it around to pass to the infobar.

Right, and that's why the delegate wraps this in a scoped ref.  I wasn't
proposing removing that one.  I was proposing removing the scoped ref we create
_here_ just to pass to the constructor which then refs it (again) in the member
object.

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/u...
File chrome/browser/ui/android/infobars/instant_apps_infobar.h (right):

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/u...
chrome/browser/ui/android/infobars/instant_apps_infobar.h:13: class
InstantAppsInfoBar : public ConfirmInfoBar {
On 2016/08/23 21:30:28, Maria wrote:
> On 2016/08/23 07:59:22, Peter Kasting wrote:
> > Subclassing ConfirmInfoBar seems wrong.  Seems like you should be
subclassing
> > InfoBarAndroid.
> 
> ConfirmInfoBar is a subclass of InfoBarAndroid that sets up some shared
> boilerplate for all infobars of this type.

Argh.  I wish that were named ConfirmInfoBarAndroid.  ConfirmInfoBar is also the
name of a views InfoBar subclass.  I was thinking of that one.

[Maria, 2016-08-23 23:55:59]

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/a...
File chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc
(right):

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc:20:
java_delegate_.Reset(Java_InstantAppsInfoBarDelegate_create(
On 2016/08/23 22:10:57, Peter Kasting wrote:
> On 2016/08/23 21:30:27, Maria wrote:
> > On 2016/08/23 07:59:22, Peter Kasting wrote:
> > > Do we really need both a Java infobar and a Java infobar delegate?  Seems
> like
> > > most Android infobars get by with just the former.
> > > 
> > > And it seems like usually, when the Java side wants to access the C++
> > delegate,
> > > the Java infobar has a pointer to the C++ infobar, and from there it can
get
> > at
> > > the infobar delegate.  I'm uneasy about having an object that has a direct
> > > pointer to this delegate.
> > 
> > Many Java infobars actually do have java infobar delegates, see:
> > 
> > AppBannerInofBarDelegateAndroid, DataReductionPromoInfoBarDelegate,
> > GeneratePassowrdSavedInfoBarDelegate, PermissionUpdateInfoBarDelegate
> > 
> > I view the delegate as the controller for the infobar where the view is the
> > infobar class itself.
> > 
> > The pointer is needed when making calls from java to native. This CL
currently
> > doesn't do it, but it ostensibly might. I am just putting in the basics for
> now.
> 
> Are you sure it will need this in the future?  If not, don't add it until you
> know you need it.
> 
> > And it seems like the other delegates do this. What's the reason you think
> > Java-side shouldn't have access to the delegate?
> 
> You can always get at the infobar delegate from the infobar, but not the other
> way around.  And it seems like the Java side should have a pointer to the
> infobar anyway.  Isn't that what the Java_InfoBar_setNativeInfoBar call in the
> InfoBarAndroid code sets up?
> 
> So I would assume you don't also need a direct delegate pointer.

Done.

https://chromiumcodereview.appspot.com/2267463002/diff/40001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc:53:
base::android::ScopedJavaGlobalRef<jobject>(jdata)));
On 2016/08/23 22:10:57, Peter Kasting wrote:
> On 2016/08/23 21:30:27, Maria wrote:
> > On 2016/08/23 07:59:22, Peter Kasting wrote:
> > > AndroidDownloadManagerOverwriteInfoBarDelegate just passes this in as a
> > jobject
> > > by value instead of constructing a ScopedJavaGlobalRef here.  The scoped
ref
> > > doesn't seem to buy much anyway given that the infobar delegate constructs
> its
> > > own, so this ref lives only for the life of the function call.  Seems like
> we
> > > should just nuke it.
> > 
> > No, this data is used by InstantAppsInfoBar::CreateRenderInfoBar(). If we
> don't
> > wrap this into ScopedJavaGlobalRef, the java object can be garbage collected
> in
> > java heap, but we need to keep it around to pass to the infobar.
> 
> Right, and that's why the delegate wraps this in a scoped ref.  I wasn't
> proposing removing that one.  I was proposing removing the scoped ref we
create
> _here_ just to pass to the constructor which then refs it (again) in the
member
> object.

Done.

[Peter Kasting, 2016-08-24 04:04:06]

LGTM modulo one notable thing

https://chromiumcodereview.appspot.com/2267463002/diff/80001/chrome/browser/a...
File chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc
(right):

https://chromiumcodereview.appspot.com/2267463002/diff/80001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc:24:
std::move(delegate)));
Nit: Optional shorter version:

  infobar_service->AddInfoBar(base::MakeUnique<InstantAppsInfoBar>(
      std::unique_ptr<InstantAppsInfoBarDelegate>(
          new InstantAppsInfoBarDelegate(jdata))));

It's admittedly ugly, but it's what most Create() functions end up doing.

https://chromiumcodereview.appspot.com/2267463002/diff/80001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc:30:
java_delegate_.Reset(Java_InstantAppsInfoBarDelegate_create(env));
Nit: I suggest keeping the init order here and the declaration order in the
header in sync

https://chromiumcodereview.appspot.com/2267463002/diff/80001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc:40: return
base::string16();
OK, returning string16() here is fine, but this reminds me that there's
something else you should do.

InfoBarManager enforces that you can't add dupe infobars.  It does it by running
EqualsDelegate() to check if two infobar delegates are the same.  You need to
override that, because the default impl in ConfirmInfoBarDelegate checks the
results of GetMessageText().  Therefore you run the risk that, if someone else
has an infobar that also returns the empty string from their GetMessageText(),
the two of you won't be able to both show infobars; the second one will just get
silently rejected.

So you should implement that function.  Probably you can just call
GetIdentifier() on both delegates, unless you need one instant apps infobar
delegate to be considered not the same as another, in which case you'll have to
put in whatever logic represents that.

https://chromiumcodereview.appspot.com/2267463002/diff/80001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc:56:
InfoBarService::FromWebContents(web_contents);
Nit: I'd probably inline this statement into the next (but I'd leave the one
above, it's too ugly to try to inline that -- might change it to use auto
though)

https://chromiumcodereview.appspot.com/2267463002/diff/80001/chrome/browser/a...
File chrome/browser/android/instantapps/instant_apps_infobar_delegate.h (right):

https://chromiumcodereview.appspot.com/2267463002/diff/80001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.h:21:
base::android::ScopedJavaGlobalRef<jobject> data() { return data_; }
Nit: I'd put a blank line above this

[Maria, 2016-08-24 17:53:49]

https://chromiumcodereview.appspot.com/2267463002/diff/80001/chrome/browser/a...
File chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc
(right):

https://chromiumcodereview.appspot.com/2267463002/diff/80001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc:24:
std::move(delegate)));
On 2016/08/24 04:04:06, Peter Kasting wrote:
> Nit: Optional shorter version:
> 
>   infobar_service->AddInfoBar(base::MakeUnique<InstantAppsInfoBar>(
>       std::unique_ptr<InstantAppsInfoBarDelegate>(
>           new InstantAppsInfoBarDelegate(jdata))));
> 
> It's admittedly ugly, but it's what most Create() functions end up doing.

Done.

https://chromiumcodereview.appspot.com/2267463002/diff/80001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc:30:
java_delegate_.Reset(Java_InstantAppsInfoBarDelegate_create(env));
On 2016/08/24 04:04:06, Peter Kasting wrote:
> Nit: I suggest keeping the init order here and the declaration order in the
> header in sync

Done.

https://chromiumcodereview.appspot.com/2267463002/diff/80001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc:40: return
base::string16();
On 2016/08/24 04:04:06, Peter Kasting wrote:
> OK, returning string16() here is fine, but this reminds me that there's
> something else you should do.
> 
> InfoBarManager enforces that you can't add dupe infobars.  It does it by
running
> EqualsDelegate() to check if two infobar delegates are the same.  You need to
> override that, because the default impl in ConfirmInfoBarDelegate checks the
> results of GetMessageText().  Therefore you run the risk that, if someone else
> has an infobar that also returns the empty string from their GetMessageText(),
> the two of you won't be able to both show infobars; the second one will just
get
> silently rejected.
> 
> So you should implement that function.  Probably you can just call
> GetIdentifier() on both delegates, unless you need one instant apps infobar
> delegate to be considered not the same as another, in which case you'll have
to
> put in whatever logic represents that.

Done.

https://chromiumcodereview.appspot.com/2267463002/diff/80001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.cc:56:
InfoBarService::FromWebContents(web_contents);
On 2016/08/24 04:04:06, Peter Kasting wrote:
> Nit: I'd probably inline this statement into the next (but I'd leave the one
> above, it's too ugly to try to inline that -- might change it to use auto
> though)

Done.

https://chromiumcodereview.appspot.com/2267463002/diff/80001/chrome/browser/a...
File chrome/browser/android/instantapps/instant_apps_infobar_delegate.h (right):

https://chromiumcodereview.appspot.com/2267463002/diff/80001/chrome/browser/a...
chrome/browser/android/instantapps/instant_apps_infobar_delegate.h:21:
base::android::ScopedJavaGlobalRef<jobject> data() { return data_; }
On 2016/08/24 04:04:06, Peter Kasting wrote:
> Nit: I'd put a blank line above this

Done.

[Maria, 2016-08-24 20:33:15]

The CQ bit was checked by mariakhomenko@chromium.org

[Maria, 2016-08-24 20:33:16]

The patchset sent to the CQ was uploaded after l-g-t-m from
dfalcantara@chromium.org, isherman@chromium.org, pkasting@chromium.org
Link to the patchset:
https://chromiumcodereview.appspot.com/2267463002/#ps100001 (title: "Style
changes")

[commit-bot: I haz the power, 2016-08-24 20:34:56]

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-08-24 21:12:36]

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

[commit-bot: I haz the power, 2016-08-24 21:12:38]

Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)

[Maria, 2016-08-24 21:57:13]

The CQ bit was checked by mariakhomenko@chromium.org

[Maria, 2016-08-24 21:57:13]

The patchset sent to the CQ was uploaded after l-g-t-m from
pkasting@chromium.org, isherman@chromium.org, dfalcantara@chromium.org
Link to the patchset: https://codereview.chromium.org/2267463002/#ps120001
(title: "Fix an import")

[commit-bot: I haz the power, 2016-08-24 21:58:12]

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-08-24 23:20:03]

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

[commit-bot: I haz the power, 2016-08-24 23:20:04]

Try jobs failed on following builders:
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[Maria, 2016-08-25 00:26:48]

The CQ bit was checked by mariakhomenko@chromium.org

[commit-bot: I haz the power, 2016-08-25 00:28:07]

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-08-25 02:31:12]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2016-08-25 02:33:09]

Description was changed from

==========
Implement instant apps infobar.

Has the expected visual treatment, but doesn't currently do anything
functionally.
Also no one is currently launching the infobar.

BUG=639497
==========

to

==========
Implement instant apps infobar.

Has the expected visual treatment, but doesn't currently do anything
functionally.
Also no one is currently launching the infobar.

BUG=639497

Committed: https://crrev.com/90230d6b1e2c01b34b9f30f11b82a648dead98ce
Cr-Commit-Position: refs/heads/master@{#414272}
==========

[commit-bot: I haz the power, 2016-08-25 02:33:10]

Patchset 7 (id:??) landed as
https://crrev.com/90230d6b1e2c01b34b9f30f11b82a648dead98ce
Cr-Commit-Position: refs/heads/master@{#414272}