Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

screenshot action hangs while pdf works fine #809

Closed
mikeys opened this issue Sep 26, 2016 · 5 comments
Closed

screenshot action hangs while pdf works fine #809

mikeys opened this issue Sep 26, 2016 · 5 comments

Comments

@mikeys
Copy link

mikeys commented Sep 26, 2016

Hi guys,

Trying to leverage nightmare in order to be able to convert an svg to a png.
For some reason the following gets stuck on the screenshot action:

var Nightmare = require('nightmare')
var nightmare = Nightmare({show: true})
var url = "file:///Users/username/Pictures/whatever.svg"
var userAgent = "Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36"

nightmare
  .useragent(userAgent)
    .goto(url)
  .wait('svg')
  .evaluate(() => {
    const svgElem = document.querySelector('svg')

    return {
      width: svgElem.scrollWidth,
      height: svgElem.scrollHeight
    }
  })
  .then(function(dimensions) {
    return nightmare
      .viewport(dimensions.width, dimensions.height)
      .screenshot('./screenshot.png')
  })
  .then(function() {
    console.log('done')
    nightmare.end()
  })
  .catch(function(err) {
    console.log('error', err)
  })

Logs:

  nightmare queuing process start +0ms
  nightmare queueing action "useragent" +2ms
  nightmare queueing action "goto" for file:///Users/username/Pictures/whatever.svg +1ms
  nightmare queueing action "wait" +1ms
  nightmare queueing action "evaluate" +0ms
  nightmare running +1ms
  nightmare:actions .useragent() to Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36 +360ms
  nightmare:log Navigating: "file:///Users/username/Pictures/whatever.svg",
            headers: [none],
            timeout: 30000 +8ms
  nightmare:log did-start-loading +63ms [{}]
  nightmare:log did-get-response-details +77ms [{},true,"file:///Users/username/Pictures/whatever.svg","file:///Users/username/Pictures/whatever.svg",200,"GET","",{"access-control-allow-origin":["*"]},"mainFrame"]
  nightmare:log dom-ready +91ms [{}]
  nightmare:log did-frame-finish-load +0ms [{},true]
  nightmare:log did-finish-load +1ms [{}]
  nightmare:log did-stop-loading +1ms [{}]
  nightmare:actions .wait() for svg element +1ms
  nightmare:actions .evaluate() fn on the page +6ms
  nightmare queueing action "viewport" +3ms
  nightmare queueing action "screenshot" +0ms
  nightmare running +0ms
  nightmare:actions .viewport() +0ms
  nightmare:actions .screenshot() +29ms
  nightmare:log subscribing to browser window frames +1ms
  nightmare:log altering page to force rendering +0ms

using pdf instead of screenshot does not get stuck. Any idea what may be causing this?

@yovchev
Copy link
Contributor

yovchev commented Sep 28, 2016

Check this out #761

@rosshinkley
Copy link
Contributor

@daniel3d is right: .end() queues the ending action, it still needs to be executed with a .then().

Setting that aside, and this is kind of offtopic: I'm not certain Nightmare is the best tool for converting SVGs to PNGs. Have you considered using something like ImageMagick? convert will give you much more flexibility for image manipulation.

@mikeys
Copy link
Author

mikeys commented Sep 29, 2016

@rosshinkley unfortunately not for SVGs :)

Mr0grog added a commit to Mr0grog/nightmare that referenced this issue Dec 16, 2016
Since the initial implementation of `FrameManager`, Electron added an API for Chromium's remote debugging protocol. One of the debugger's capabilities is to visually highlight a portion of the page. This change uses that functionality to force a new frame to be rendered. This is much more reliable than the way Nightmare currently tries to force new frames to render by fiddling around with the DOM (see issues segment-boneyard#555, segment-boneyard#736, segment-boneyard#809). It also has the benefit of not doing anything page content can observe, ensuring that any JS or CSS won't modify the page in response to Nightmare's attempt to take a screenshot.

In future versions of the protocol, it will be possible to directly capture an image of the page, but that feature is still experimental (so it could be removed) and Electron does not yet support it anyhow. Something to keep in mind for future changes, though.

This is an alternative solution to the one in 53dee8a (currently on the `screenshot-with-offscreen-rendering` branch). That method (using Electron's new "offscreen" rendering mode) is *much* faster than this and vastly simplifies the code, but has more ways it can fail.
Mr0grog added a commit to Mr0grog/nightmare that referenced this issue Dec 16, 2016
Sometime mid-year, Electron added support for "offscreen" rendering (it still shows a window, but the whole rendering pipeline is a bit different). When this mode is enabled, the rendered view can be explicitly invalidated, which is *much* better and more reliable than the way Nightmare currently tries to force new frames to render by fiddling around with the DOM (see issues segment-boneyard#555, segment-boneyard#736, segment-boneyard#809).

This isn't without its downsides; it doesn't work with forced device scale factors and it renders differently than with native system rendering (e.g. text rendering will be slightly different).
@Mr0grog
Copy link
Contributor

Mr0grog commented Dec 16, 2016

Anyone here experiencing timeouts may want to give the #927 a try. There’s also second approach to solving this over on https://github.com/mr0grog/nightmare/tree/screenshot-with-offscreen-rendering that you might give a try.

@rosshinkley
Copy link
Contributor

Considering this fixed with #927. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants