The issue seems to be out of TE-scope as it is related to puppeteer automation tool to test the issue. Hence, adding label TE-NeedsTriageHelp for further investigation from dev team.

Thanks...!!

Peter, it is that issue again...

Nah, this is something else.  This seems to be reporting that the renderer thinks the viewport is larger than it really is?  Otherwise why would there be an issue seeing elements at the bottom of the screen?  You could just make sure the overall Chrome window was larger.

Reporter, can you clarify why your page-bottom elements aren't visible?  A test site/repro case might help.

I think it is the same. User emulates given resolution and then infobar affects things.

The same as what?  I thought you were talking about bug 804324, but that's about infobar animations during page load causing a perf hit.  It's also about a different infobar.  Are you thinking of a different bug?

I don't know what "User emulates given resolution" means either.  If someone is starting Chrome with a particular viewport size, but showing the infobar causes us to not open at that size, we should fix the window-size-from-viewport-size computation to take that infobar into account.  If someone is showing Chrome with a particular window size expecting a particular viewport size, that's fragile and will break as we change Chrome's UI; they need to use a different window size.  If this is something else, then I don't yet understand the issue.

I was mentioning this broader issue to you when we were talking about bug 804324. Here is the broad definition:

"When running for testing or automation, Chrome should not show infobars that might affect web size, metrics or performance."

We were discussing the overlay for the "running for automation".

>> If someone is showing Chrome with a particular window size expecting a particular viewport size, that's fragile and will break as we change Chrome's UI; they need to use a different window size.  If this is something else, then I don't yet understand the issue.

Puppeteer and other automation drivers are setting particular viewport size in a way that is not fragile (through low level emulation). And clients of these frameworks are indeed looking for the guarantees for these to not be fragile.

In this case, Infobar shifts the web contents via re-layouting the main window. Web metrics are still emulated, but part of the viewport is not visible to the user. It also makes it impossible to readback from GPU, so screenshots might be cropped. But the underlying issue is the same: chrome should respect the 'automation' mode and not show infobars in that mode to fix entire class of problems.

Sorry, there is a small problem with the report. It's v65 that affects us, not v64.

The issue is that if you have an element that fills the viewport vertically (height:100%/100vh) and have elements fixed to the bottom of the element/viewport (i.e. css= position: absolute; bottom: 0px;), then the automated testing infobar shifts the viewport down by 44px, which is outside of the Chrome window. The bottom elements get clipped.

Making the Chrome window larger doesn't fix this unless the viewport height is also reduced (by minus 44px).

In my case (see attached clip), I have a fixed viewport height of 720px. Elements that are    
positioned less than 43px from the bottom of the viewport are now getting clipped because of the infobar.

Deleted: v64-disable-infobars.png 287 KB

	v64-disable-infobars.png 287 KB View Download

Deleted: v65-with-infobar.png 393 KB

	v65-with-infobar.png 393 KB View Download

I guess my point is that even if one proposed fix addresses both issues, these are distinct bugs.  This matters because who knows when I'll have time to implement some kind of new UI for this, but maybe there are separate workarounds for these in the meantime.

It's surprising that you say that adding an infobar would cause the viewport to be shifted rather than shrunk.  That's not how I read the code in browser_view.cc (it should resize the content area, not shift + clip) and doesn't seem to be how this works for infobars in normal use.  I'd have expected the bug to be "we asked for a 100x100 viewport but only got 100x80" (or whatever).

Dgozman@ is suggesting a single red infobar when running with --enable-automation. And hide all other infobars in that mode.

Specifically, I thought the resize code was supposed to shift down during animation, but then do a true viewport resize at the end, which should cause the page content to relayout.  Either I'm misunderstanding the code, this doesn't happen all the time, or the screenshots etc. are getting captured before that happens.

@12: Having any infobars at all is as bad as having n infobars.  I think the long-term UI change is the one on bug 804324 comment 71.

Yes, comment 9 is a better explanation of the issue with regards to Puppeteer in general.

I've checked and screenshots using the dev tools api are not affected.  What gets displayed on-screen is, and so might affect automation cases.  

In our case, we're doing a screengrab to capture video of the window, but can see that this would affect other automation use cases.

The change with removing "--disable-infobars" makes it impossible for us to upgrade to Chrome 65 in our performance tests. We drive Chrome with Selenium/Chromedriver and record a video of the screen, and then analyze the video using VisualMetrics. The bars breaks our first visual change. 

If you really really needed to remove the flag, what about just do as Firefox, they show that the browsers is automated by changing the favicon in the the browser bar? Changing content on the screen with infobars will always makes it hard when you record the screen.

As noted in comment 14, the long-term fix proposal here is to move away from infobars.  The issue is bandwidth.  I am heavily oversubscribed right now, so some help implementing the change there would move the timeline from "who knows" to "soon".

> Having any infobars at all is as bad as having n infobars

Having one static infobar in case of --enable-automation would solve all the automation problems. I can try implementing this if you agree to review it.

I don't understand how that would solve anything.  The issue is that there is an infobar.  Having any infobars still causes the viewport sizing issues and problems taking screenshots.

Possible solution: disable all infobar animation when automation is enabled.  pfeldman is going to check whether this actually addresses the issue or not.

@dave: could you paste your pptr script here?

 Issue 820011  has been merged into this issue.

 Issue chromedriver:2301  has been merged into this issue.

Morphing.

This is now the master bug on "provide a non-infobar warning UI, switch at least --enable-automation to it".  The proposed warning UI is "overlay the top chrome (not the content area) with 50% white, display a message about the browser being automatically controlled, along with a link to learn more".

Probably if --enable-automation uses this, it should also disable all infobars.  That can be covered on this bug too because I don't know of a better place.

Probably if this is implemented GlobalClonfirmInfoBar should go away, but I'm not 100% sure.

Having the warning UI tied to --enable-automation is not enough. It's really the --remote-debugging-port switch that gives other apps control over Chrome. 99% of ChromeDriver features work fine without --enable-automation, only --remote-debugging-port is required.

I would say the scope of this bug is "switch to the new UI whatever command-line flag currently causes us to warn users".  I don't actually know what flag that is.  If it's not the right one, I suggest filing a separate bug that's basically "please change from warning on flags A, B, C to flags A, C, D".

Issue 827214 has been merged into this issue.

I intend to close this due to no activity and no concrete plan on going forward. Please feel free to reopen with the plan of action.

Is comment 24 insufficiently concrete?