GithubHelp home page GithubHelp logo

Comments (14)

joelgriffith avatar joelgriffith commented on May 18, 2024 1

Shoot, think I found it:

chrome = new Chrome({
  headless: true,
  disableGpu: true,
  hideScrollbars: true,
  noSandbox: true
})

Should be:

chrome = new Chrome({
  flags: {
    headless: true,
    disableGpu: true,
    hideScrollbars: true,
    noSandbox: true
  }
})

Just checked, docs did have right (whew): https://joelgriffith.github.io/navalia/chrome/constructor/

from navalia.

joelgriffith avatar joelgriffith commented on May 18, 2024

Thanks for the feedback, appreciated! I'll have to dig into the handshake that happens at the websocket layer (which is why I think this is failing). Those machines that don't work either aren't opening up their ports for debuggers to connect or something else is blocking the connection.

Sorry your having issues, hopefully we can get to the bottom of this!

from navalia.

mpeyper avatar mpeyper commented on May 18, 2024

Just to clarify, you suspect it's the debugger port for Chrome that's it failing the connection?

from navalia.

joelgriffith avatar joelgriffith commented on May 18, 2024

Yes, when the program starts up it launches chrome, and passes a flag to it with the port to open for debugging. It's my guess that Chrome isn't respecting that (don't have hard evidence in support of that, however).

A similar issue was once filed prior, and the solution there was to use Chrome Canary, which supports a wider set of remote functionality. My version outputs:

Google Chrome is up to date
Version 61.0.3156.0 (Official Build) canary (64-bit)

You might also attempt to run your tests like so:

$ DEBUG=* npm run test // replace with your test command

This will trigger all the underneath libraries to print out statements, which might give a better indicator of where your problem resides.

from navalia.

mpeyper avatar mpeyper commented on May 18, 2024

@joelgriffith

The DEBUG=* has produced a bit of a clue (as well as thousands of lines of babel output)

On the CI, the output is

navalia:chrome :getChromeCDP() > starting chrome +0ms
ChromeLauncher Waiting for browser..... +917ms
ChromeLauncher Waiting for browser....... +508ms
ChromeLauncher Waiting for browser......... +528ms
ChromeLauncher Waiting for browser........... +501ms
ChromeLauncher Waiting for browser............. +501ms
ChromeLauncher Waiting for browser............... +502ms
ChromeLauncher Waiting for browser................. +502ms
ChromeLauncher Waiting for browser................... +500ms
ChromeLauncher Waiting for browser..................... +502ms
ChromeLauncher Waiting for browser....................... +501ms
ChromeLauncher:error connect ECONNREFUSED 127.0.0.1:33944 +1ms
ChromeLauncher:error Logging contents of /home/bamboo/.tmp/lighthouse.ZkfpNHk/chrome-err.log +0ms
ChromeLauncher:error [0714/084153.449293:FATAL:zygote_host_impl_linux.cc(107)] No usable sandbox! Update your kernel or see https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md for more information on developing with the SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.
ChromeLauncher:error  +0ms
navalia:chrome :done() > finished +2ms

We tried starting Chrome with

chrome = new Chrome({
  headless: true,
  disableGpu: true,
  hideScrollbars: true,
  noSandbox: true
})

but it didn't help.

from navalia.

mpeyper avatar mpeyper commented on May 18, 2024

We have also tried on another dev's machine and the tests work there too, so not sure what is wrong with the IPv6 one from the first post.

For the record, DEBUG=* output from my machine is

  navalia:chrome :getChromeCDP() > starting chrome +0ms
  ChromeLauncher Waiting for browser. +285ms
  ChromeLauncher Waiting for browser... +0ms
  ChromeLauncher Waiting for browser..... +511ms
  ChromeLauncher Waiting for browser.....✓ +1ms
  navalia:chrome :getChromeCDP() > chrome launched on port 59671 +36ms
  navalia:chrome :goto() > going to http://localhost:3000 +0ms
  navalia:chrome :goto() > waiting for pageload on http://localhost:3000 +1ms
  navalia:chrome :wait() > waiting 500 ms +22ms
  navalia:chrome :exists() > checking if '#root' exists +506ms
  navalia:chrome :done() > finished +4ms
  navalia:chrome :done() > closing chrome +0ms
  ChromeLauncher Killing all Chrome Instances +0ms

from navalia.

joelgriffith avatar joelgriffith commented on May 18, 2024

Nice trace, that's helpful! Looks like the issue is in chrome-launcher package that Navlia uses. This issue seems quite similar even: GoogleChrome/lighthouse#2661

Do you know what version of Chrome runs on those CI boxes? My sense is it's coming from a version incompatibility of some kind.

This issue too might be similar GoogleChrome/lighthouse#2462

from navalia.

mpeyper avatar mpeyper commented on May 18, 2024

Chrome version is 59.0.3071.115 (same as the one in that issue)

from navalia.

mpeyper avatar mpeyper commented on May 18, 2024

It's the same version I am using though on my macbook though... just to confuse things.

from navalia.

joelgriffith avatar joelgriffith commented on May 18, 2024

I'm going to be looking into running functional tests with Travis for this Project, so I'll see if I can repro there.

from navalia.

mpeyper avatar mpeyper commented on May 18, 2024

@joelgriffith

So I have an update... we did something really hacky (don't ask how) and replaced the flags provided to chrome to enforce the --no-sandbox flag and the test passes on the CI box.

When we used noSandbox: true like in the above comment, it had no effect. We're looking into why now.

from navalia.

joelgriffith avatar joelgriffith commented on May 18, 2024

Definitely possible that Navalia isn't passing them through properly... I'll take a peak

from navalia.

mpeyper avatar mpeyper commented on May 18, 2024

Soooooo... yeah that was it. Removed our hacks and crazy long timeouts, set the flags correctly and we now have a passing integration test on out build.

Thanks so much @joelgriffith, you can close this one and file it under "user error".

As a side note, we still have one dev's machine that can't run it, but it seems to be something unique to his setup.

from navalia.

joelgriffith avatar joelgriffith commented on May 18, 2024

Thanks for hunting it down! I need to capture these in a FAQ of some kind. Happy hacking!

from navalia.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.