+johnchen fyi
@dgozman, do you have an idea on what is happening?

Our issue is that we use Selenium and Chrome to drive displays in our corporate campus.  We can't have that message displayed on top of our content.  There must be an alternative.

@2: Can you say more about why you need to use Selenium?  Why is e.g. --kiosk plus a page that auto-navigates as necessary not a suitable alternative?

I think the issue you're reporting is slightly different than comment 0, though -- you're frustrated by having a visible message, whereas comment 0 is frustrated by coordinate changes (which might be WontFix; clicking on elements rather than coordinates sounds better to me, but I'm also not a Selenium expert).

pfeldman@, I feel like I tried to write a quick CL to rip out a dead flag at the behest of the security/tools folks and now I'm getting flooded with fallout from it.  Is it OK if I assign this to you and let you morph/dupe bugs as necessary into some single thing that dictates a solution that will make all the interested parties maximally happy?  I don't understand the constraint space well enough here and I'm too overloaded to know what to do.

Do we need to reinstate --disable-infobars as an emergency measure until we figure out the right way to get rid of it?

> Is it OK if I assign this to you and let you morph/dupe bugs as necessary into some single thing that dictates a solution that will make all the interested parties maximally happy?

Sounds good.

> Do we need to reinstate --disable-infobars as an emergency measure until we figure out the right way to get rid of it?

I think so. We would want to merge it into M66 at least and make sure ChromeDriver is using it.

I'm not sure what we can do for our stable users, but that's beyond Peter's scope. I'll be suggesting non-testing/automation users to look at

https://github.com/GoogleChrome/puppeteer and
https://miyakogi.github.io/pyppeteer/

in the interim. One can write simple automation scripts there with ease,

headless: false, appMode: true options make it open Chrome window, one can attach to existing chrome as well. They should be sufficient to do anything ChromeDriver can do in M65.

Hi,

I'll try to explain what is happening now when infobars can't be disabled.

When you find an element on page that is in visible area then you will receive some coordinates of it. Problem is that if something is above these coordinates (like this inforbar or some info window of current page you test) then you might not be able to click on it unless you "manually" scroll window so element is not hidden. 

So sometimes you must "tune" tests so they scroll window sometimes and we use static window resolution because of that as well.

Problem is that this infobar will lower visible area so your "finetuning" will not work

Maybe these is problem in our tests (I am not Selenium guru) but we need this infobar hidden otherwise visible area is changed and some tests broke

br, Vladan
When this

--disable-infobars is back

--disable-infobars is not preventing Chrome's first start up after install, to prompt the user about being the default browser. We are using Chrome as a kiosk within a docker container. Whenever a docker container is run it is Chromes first start up. This ensures we have complete control of the environment. But I can't think of a way to get around it.

If --disable-infobars is back, and I'm assuming disable infobars is the same thing that prompts the user about the default browser, what Chrome version should have --disable-infobars?