Behavior of setViewport() inconsistent in Headful #1910

alixaxel · 2018-01-28T13:23:48Z

Environment:

Puppeteer: 1.0.0
Platform / OS: Ubuntu 16.04 LTS (1920x1080@1x)
Node.js: 8.9.3
Chromium: 65.0.3312.0 (Developer Build) (64-bit)

What steps will reproduce the problem?

Running the following code several times.

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch({
    args: [
      '--start-maximized',
    ],
    headless: false,
  });

  const page = await browser.newPage();

  /**
   * This should make Chromium infer current screen resolution (only in headless = false).
   */
  await page.setViewport({
    width: 0,
    height: 0,
  });

  await page.goto('http://matanich.com/test/viewport-width', {
    waitUntil: [
      'domcontentloaded',
      'load',
    ],
  });

  let result = await page.evaluate(
    () => {
      return window.innerWidth;
    }
  );

  console.log(`Detected window.innerWidth to be ${result}.`);

  await browser.close();
})();

What is the expected result?

I should get the save window.innerWidth all the time.

What happens instead?

Seems that sometimes setViewport() fails silently and fallbacks to the default viewport size of 800x600.

$ node setViewportTest.js
Detected window.innerWidth to be 1855.

$ node setViewportTest.js
Detected window.innerWidth to be 1855.

$ node setViewportTest.js
Detected window.innerWidth to be 800.

$ node setViewportTest.js
Detected window.innerWidth to be 1855.

$ node setViewportTest.js
Detected window.innerWidth to be 1855.

$ node setViewportTest.js
Detected window.innerWidth to be 1855.

$ node setViewportTest.js
Detected window.innerWidth to be 800.

The text was updated successfully, but these errors were encountered:

alixaxel · 2018-01-28T13:28:22Z

Also experimented adding a await page.waitFor(500); after setViewport() and goto().

Same results. 😕

aizuyan · 2018-01-28T13:34:28Z

➜  testChromium node t.js
Detected window.innerWidth to be 800.
➜  testChromium node t.js
Detected window.innerWidth to be 800.
➜  testChromium node t.js
Detected window.innerWidth to be 800.
➜  testChromium node t.js
Detected window.innerWidth to be 800.
➜  testChromium node t.js
Detected window.innerWidth to be 800.
➜  testChromium node t.js
Detected window.innerWidth to be 800.

Puppeteer: 1.0.0
Platform / OS: Darwin localhost 17.2.0 Darwin Kernel Version 17.2.0
Node.js: v9.3.0
Chromuim: 66.0.3334.0

aslushnikov · 2018-01-29T02:23:13Z

@alixaxel @aizuyan interesting. Can you guys share your user scenario?

aizuyan · 2018-01-29T06:27:52Z

@aslushnikov THX, I want to create a page demo, show the full page to someone else, but now only show part of viewport.

alixaxel · 2018-01-30T06:42:57Z

@aslushnikov Actually I would just like to use this while developing.

I almost always use Chrome maximized, and while developing with PPTR, one of several things happen:

I leave viewport/window size untouched and I often end up with mobile media queries
I set a fixed viewport size but window size is smaller, causing horizontal scroll
I set a fixed viewport size and full screen window, causing large part of the screen to be blank

It is helpful to have PPTR match the behavior of my Chrome, no matter which computer/resolution I'm at.

Granted, it's not a huge issue, but I find the inconsistency intriguing.

aizuyan · 2018-01-30T08:47:00Z

when i delete some code, that be ok:

file lib/Page.js

line 56~58

code

// Initialize default page size.
if (!appMode)
    await page.setViewport({width: 800, height: 600});

I think maybe the setViewport don't go into effect when i call it in my code.

alixaxel · 2018-01-30T08:54:50Z

@aizuyan You don't need to delete it, can just pass appMode: true to Browser options:

https://github.com/GoogleChrome/puppeteer/blob/f2b6016354670ed8300285e0ae25894e3bc5c8e9/lib/Launcher.js#L68-L69

However, I have no idea what this option is for, it's not documented anywhere.

BTW, care to clarify what you mean by "that be ok"?

aizuyan · 2018-01-30T09:24:59Z

@alixaxel
Thanks very much.
I mean I can create a page demo that show 100% viewport.

my english is poor 😶🙃🙂

aslushnikov · 2018-09-04T23:19:48Z

I can't reproduce this as of puppeteer v1.7.0. @alixaxel is this still relevant to you?

P.S. There's now a defaultViewport: null option that you can pass to puppeteer.launch to disable viewport overrides.

o0101 · 2020-02-04T13:43:44Z

I work around this by setting the Browser.setWindowBounds

to {width: width, height: height + 64}

where I guess 64 to approximate the window chrome above the tab viewport in regular headful chrome.

o0101 · 2020-02-04T13:44:57Z

This helps prevent the irregularity of Emulation.setVisibleSize sometimes reverts back to the window bounds when in headful mode. I have not seen this happen in headless mode.

zmorris · 2020-11-17T03:04:13Z

I was struggling with a similar issue (trying to resize the viewport in headless), but thanks to aslushnikov's answer on another thread I was able to use this workaround function for both headful and headless modes:

async function setWindowSize(page, width, height) {
  if(headless) {
    const session = await page.target().createCDPSession();
    const {windowId} = await session.send('Browser.getWindowForTarget');
    await session.send('Browser.setWindowBounds', {windowId, bounds: {width: width, height: height}});
    await session.detach();
  } else {
    await page.setViewport({width: width, height: height});
  }
}

Apologies that it isn't the most idiomatic async Javascript code..

I would use Browser.setWindowBounds() everywhere, but unfortunately it has inconsistent behavior in headful. It doesn't seem to account for the dimensions of UI elements like the address bar and navigation controls. Which would make sense since those probably don't exist in headless mode.

Maybe someone can put together a workaround that measures the width/height differences between the two methods upon the first call in headful, then accounts for those differences during subsequent calls. That way Browser.setWindowBounds() could be used everywhere until the Puppeteer devs get time to fix this.

Note that the width also seems to be inconsistent, but that could be due to css rules in my project. Also the sizes are different between headless and headful, so to avoid a bunch of false positives, you'll need to run your tests completely in one mode or the other for now. In my case that's fine, since I was just trying to make window resizing work headless.

If any of the devs read this, please please remove all runtime differences due to implementation details between headful and headless. We shouldn't have to worry about the window bounds not working just because we're running headless. I realize that this is probably a goal of yours, and that you probably have your hands tied by the Chrome devs not realizing the we still need to resize windows during development:

https://bugs.chromium.org/p/chromium/issues/detail?id=2091

LeviPesin · 2022-06-09T15:05:50Z

Maybe someone can put together a workaround that measures the width/height differences between the two methods upon the first call in headful, then accounts for those differences during subsequent calls. That way Browser.setWindowBounds() could be used everywhere until the Puppeteer devs get time to fix this.

The only workaround I found to be working is manually adding 16 to the width and 133 to the height (these numbers are different on different platforms...). Does anyone find a more automatic workaround?

I tried setting bounds and then measuring client width and height (by Page.getLayoutMetrics, by document.documentElement, by screenshoting the page) and setting bounds again, but for some reason client width and height are the same as the values set.

LeviPesin · 2022-06-10T08:16:15Z

by screenshoting the page

I guess I forgot to disable defaultViewport option. Will try to compile a workaround with it...

LeviPesin · 2022-06-10T10:37:36Z

So, I have found a workaround, but it requires capturing screenshot in the fromSurface: false mode which is not supported by Puppeteer until #8496:

const { windowId } = await session.send( 'Browser.getWindowForTarget' );
await session.send( 'Browser.setWindowBounds', { windowId, bounds: { width, height } } );
const { width: clientWidth, height: clientHeight } = ( await jimp.read( await captureFromSurfaceFalse( session ) ) ).bitmap;
await session.send( 'Browser.setWindowBounds', { windowId, bounds: { width: 2 * width - clientWidth, height: 2 * height - clientHeight } } );

It works with defaultViewport, because fromSurface ignores it.

LeviPesin · 2022-06-10T10:41:49Z

If desired, I can make a PR with this workaround after #8496 will be merged. /ping @jrandolf @OrKoN

LeviPesin · 2022-06-10T11:56:30Z

Seems like the fromSurface: false adds a Windows applications "shadow" to the top of the image (but it does not break the workaround, I think)... ~~Also, it seems to screenshot scrollbars...~~ (--hide-scrollbars options can be used)

stale · 2022-08-15T16:38:07Z

We're marking this issue as unconfirmed because it has not had recent activity and we weren't able to confirm it yet. It will be closed if no further activity occurs within the next 30 days.

yanghoxom · 2024-03-20T18:54:34Z

You can think about '--window-size=375,667', if you want set width height in initialize state

alixaxel mentioned this issue Jan 30, 2018

"Non-deterministic" screenshots after viewport resize #1751

Closed

alixaxel mentioned this issue Feb 5, 2018

docs(api): document appMode #1954

Closed

aslushnikov mentioned this issue Feb 27, 2018

v2.0 Breaking Changes #2079

Closed

13 tasks

ebidel mentioned this issue Feb 27, 2018

Some https requests are not intercepted #2111

Closed

aslushnikov added the chromium Issues with Puppeteer-Chromium label Dec 6, 2018

LeviPesin mentioned this issue Jun 9, 2022

Puppeteer E2E test: many changes mrdoob/three.js#24109

Closed

21 tasks

LeviPesin mentioned this issue Jun 16, 2022

feat: add fromSurface option #8496

Merged

stale bot added the unconfirmed label Aug 15, 2022

OrKoN added bug upstream confirmed and removed unconfirmed labels Sep 5, 2022

OrKoN added the P3 label May 9, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Behavior of setViewport() inconsistent in Headful #1910

Behavior of setViewport() inconsistent in Headful #1910

alixaxel commented Jan 28, 2018 •

edited

alixaxel commented Jan 28, 2018

aizuyan commented Jan 28, 2018

aslushnikov commented Jan 29, 2018

aizuyan commented Jan 29, 2018

alixaxel commented Jan 30, 2018

aizuyan commented Jan 30, 2018

alixaxel commented Jan 30, 2018 •

edited

aizuyan commented Jan 30, 2018

aslushnikov commented Sep 4, 2018

o0101 commented Feb 4, 2020

o0101 commented Feb 4, 2020

zmorris commented Nov 17, 2020 •

edited

LeviPesin commented Jun 9, 2022 •

edited

LeviPesin commented Jun 10, 2022

LeviPesin commented Jun 10, 2022 •

edited

LeviPesin commented Jun 10, 2022 •

edited

LeviPesin commented Jun 10, 2022 •

edited

stale bot commented Aug 15, 2022

yanghoxom commented Mar 20, 2024

Behavior of setViewport() inconsistent in Headful #1910

Behavior of setViewport() inconsistent in Headful #1910

Comments

alixaxel commented Jan 28, 2018 • edited

alixaxel commented Jan 28, 2018

aizuyan commented Jan 28, 2018

aslushnikov commented Jan 29, 2018

aizuyan commented Jan 29, 2018

alixaxel commented Jan 30, 2018

aizuyan commented Jan 30, 2018

alixaxel commented Jan 30, 2018 • edited

aizuyan commented Jan 30, 2018

aslushnikov commented Sep 4, 2018

o0101 commented Feb 4, 2020

o0101 commented Feb 4, 2020

zmorris commented Nov 17, 2020 • edited

LeviPesin commented Jun 9, 2022 • edited

LeviPesin commented Jun 10, 2022

LeviPesin commented Jun 10, 2022 • edited

LeviPesin commented Jun 10, 2022 • edited

LeviPesin commented Jun 10, 2022 • edited

stale bot commented Aug 15, 2022

yanghoxom commented Mar 20, 2024

alixaxel commented Jan 28, 2018 •

edited

alixaxel commented Jan 30, 2018 •

edited

zmorris commented Nov 17, 2020 •

edited

LeviPesin commented Jun 9, 2022 •

edited

LeviPesin commented Jun 10, 2022 •

edited

LeviPesin commented Jun 10, 2022 •

edited

LeviPesin commented Jun 10, 2022 •

edited