Weird headless post Chrome 144 issue of TINY rendered area

[Michael Vederman]

Hello,

We run headless automation bots which use selenium and chromedriver and post 144 we are getting failures we just do not understand.

We saw this start in Chrome 144 and hoped it would be resolved in 145 which we updated to today, but no.

The issue is the rendered area is tiny.

This is happening for multiple bots with different automation libraries, but both use selenium and chromedriver.

This is not consistent, sometimes it will work, some bots don't suffer from this issue, we are looking for a common thread and a way to mitigate this.

The result, as one can expect, is that the page layout is changed and causes some element interaction issues.

When out bot fails, it takes a screenshot and what we see is a tiny sliver that is 1/20th or less the size of the window.

What in sam hill is this?!

tia, mike

[Michael Vederman]

well, that image is way too small. here is the right hand side where you can see the scrollbar, that's all that is rendered and that taking a screenshot gets.

[Michael Vederman]

we can say this first appeared on Feb 3. using chromedriver 144.0.7559.109 on some version of chrome higher than 144.0.7559.97 (i don't have the specifics).

it's not consistent, sometimes it happens, sometimes it doesn't. the same bot will error then run fine it seems, whether it runs fine with a reduced screen i can't say, we only take a screenshot on failure. only then we see the reduced window size.

once again, this is still present in chrome 145 and we see failures to this day, but it's not consistent...

i'm still running thru logs and trying to correlate other items. it is difficult to fathom this is a windows or vmware issue, however i'm still collecting data points to understand what transpired on feb 3 that changed everything. talking to corporate infrastructure now to see when they pushed out new chrome versions.

[Michael Vederman]

more info: we have a proprietary automation engine, we can switch between three technologies including puppeteer (our own library) and the screen issue is NOT appearing when we use Puppeteer. so, it feels more like some weird combination with something introduced in v144 either the chrome driver or chrome itself.

since we were stuck using the same chromedriver 144.0.7559.109 even when chrome updated (144 chromedrivers were removed from the main site way before chrome 145 was released - which is very odd, generally that lags or is in lockstep). still trying to find out if we got a new version of chrome pushed out feb 3.

but using puppeteer, not launching or being controlled via chromedriver, seems to be resolving this intermittent issue.

[Michael Vederman]

144 was particularly horrid. we can see this happening across multiple production VMs as well, so this is not isolated.

The lucky thing is it doesn't seem to happen to all sessions and it seems, on average, to work correctly or even work within the narrow window being rendered.

So far, we cannot determine a common factor other than chromedriver 144 and chrome 144.

Also, rereviewing all logs and conversations, this started on Jan 27, but it coulda been jan 24.

We are still seeing this issue TODAY, even at Chrome 145.

Someone has to know what is going on!!!

ANYONE?!

TIA, mike

[Michael Vederman]

More info, the 'main frame' being used for navigation appears to be this branding box which, iunno, is that new?

On Wednesday, 25 February 2026 at 14:36:50 UTC-6 Michael Vederman wrote:

OK, here is the definitive answer of what is going on. and i have zero clue

who can point me to the correct forum to get the developer's attentions?

What we now see is in headed mode, full chrome and what happens is the whole window opens then some tiny frame opens at the bottom with 

[Alex N. Jose]

Can you provide steps you're following, to attempt reproducing this issue at my end? Is this specific to a website being tested, or are all pages having the same issue?

Alternatively, can you make a minimal reproduction of the issue using one of the templates at https://github.com/GoogleChromeLabs/chromedriver-bug-repro-templates? Pick a template from the repo that matches your environment/technology of choice.

-- 

Thanks,

Alex

[Michael Vederman]

from what we can tell, launch a "managed by your organization" chrome via selenium with no url on the commandline, then use selenium to navigate and it will open in the branding frame.

it has occurred across multiple websites.

[Michael Vederman]

ok, i think i see what happens. it all depends upon how fast chrome can start up and whether or not it will display the start page before we issue a navigate via the backend.
i am watching it both work and fail and that is the short of it.
if there are particular policies which activate this behavior rather than the general branding box, i can get you more details.

[Michael Vederman]

I can add one more detail, we are hoping to mitigate this until it is resolved by passing in a url on the commandline.

HOWEVER, we have noticed that perhaps work was done to change consistent loading of landing pages pushed out via policies?
What I mean is that sometimes passing in the url will work, like it comes in after the corp landing page and other times it goes to the url then the corporate landing page loads.

What we cannot explain is why the chrome landing page comes up and not the corporate landing page it normally does...

it all feels inconsistent like timings have changed, priorities of processes have somehow altered... it should be consistent, i would think the url take precendence over any landing page.

[Michael Vederman]

ok, we have mitigated this by setting the default homepage in the user profile we use.

it is curious it's not navigating to the corporate landing page, so that is another bug.

for the time being, we will have to update all profiles to set the home page, but this at least means no production code changes.

i hope you resolve this, it's an interesting bug.