New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 679343 link

Starred by 1 user
Status: Fixed
Owner:
eseckler@chromium.org
Closed: Jan 2017
Cc:
skyos...@chromium.org
█ alexclarke@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

--hide-scrollbars doesn't work anymore after Target.createTarget

Reported by potoms....@gmail.com, Jan 9 2017 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36

Steps to reproduce the problem:
Chrome Version: 57.0.2970.0
OS: Linux

1. run chrome with "--headless --no-sandbox --disable-gpu --remote-debugging-port=9222 --hide-scrollbars"

2. run following node script:

var chrome = require('chrome-remote-interface');

function createTarget (devtools, options) {
  return devtools.Target.createTarget(options)
    .then(({ targetId }) => {
      return chrome.List()
        .then(list => {
          var url = list.find(target => target.id === targetId).webSocketDebuggerUrl;
          return chrome({ tab: url });
        });
    });
}

function getScreenshot (devtools, url) {
  return devtools.Page.navigate({ url })
    .then(() => new Promise(resolve => setTimeout(resolve, 3000)))
    .then(() => devtools.Page.captureScreenshot())
    .then(({ data }) => data);
}

function getScreenshotInNewTarget (devtools, url) {
  return createTarget(devtools, { url: 'about:blank' })
    .then(target => getScreenshot(target, url));
}

var url = 'https://www.google.com';

chrome({ port: 9222 })
  .then(devtools => {
    return getScreenshot(devtools, url)
      .then(initial => {
        return getScreenshotInNewTarget(devtools, url)
          .then(inNewTarget => ({initial, inNewTarget}));
      });
  })
  .then(({initial, inNewTarget}) => console.log(`
    <img src="data:image/png;base64,${initial}"/>
    <img src="data:image/png;base64,${inNewTarget}"/>
  `))
  .catch(e => console.error(e));

3. inspect the produced images

What is the expected behavior?
Both screenshots don't have scrollbars

What went wrong?
the screenshot that was made in the new target has scrollbars

Did this work before? N/A 

Chrome version: 57.0.2970.0  Channel: dev
OS Version: 
Flash Version: Shockwave Flash 24.0 r0
Screen Shot 2017-01-09 at 14.52.15.png
244 KB View Download

Comment 1 by eseckler@chromium.org, Jan 9 2017

Cc: skyos...@chromium.org alexclarke@chromium.org
Labels: Proj-Headless
Owner: eseckler@chromium.org
Status: Assigned (was: Unconfirmed)
Thanks again for filing the bug.

I think this has to do with the target being created in a different BrowserContext, which doesn't have the hide_scrollbar setting set.

We should address two things:
  a) The default BrowserContext used by Target.createTarget should be the existing BrowserContext created by headless shell.
  b) --hide-scrollbars should set the default value of the hide_scrollbars setting for all BrowserContexts. This may apply to other command line options, too.

Comment 3 by eseckler@chromium.org, Jan 13 2017 

Patch above should address a).

I intent to add the hide_scrollbars option to HeadlessBrowser::Options to address b).

skyostil@/alexclarke@: While I'm at it, should we try to add protocol_handlers there, too, so that --determistic-fetch can affect all contexts? It's a little more complicated for those, since ProtocolHandlerMap cannot currently be copied, but is modified by HeadlessBrowserContext::Builder::Build().

Comment 4 by skyos...@chromium.org, Jan 13 2017 

I'm not sure what we can do with protocol handlers because they're owned by the browser context and thus can only belong to exactly one. One option would be to install wrapper handlers that delegate back to the original ones, I'm not sure what the API for that would look like. In any case, it should be completely obvious to the user which context gets which protocol handlers to avoid introducing subtle security bugs.

Comment 6 by eseckler@chromium.org, Jan 24 2017

Status: Fixed (was: Assigned)
►

Sign in to add a comment