I am running puppeteer on a Linux VM, which does not have a display; however, I am using xvfb to remedy that.
For some background: The overall goal of this program is to navigate to a page and authenticate using puppeteer. From there, I audit several webpages using Lighthouse.
I have been running this script for several weeks in headless no issues. I've recently found that the performance metrics of the headless Lighthouse runs far better than reality by running manual tests on my local machine through chrome developer tools. If it's relevant, I specifically noticed a huge gap in the number of recorded DOM nodes. Long story short, I now need to run this script in headful mode.
After installing and implementing xvfb in my code, I have been able to start a display within my script without hitting any errors. I used the answer from this question as reference: Running Puppeteer with xfvb headless : false
With all of that out of the way, onto the actual issue: this script, including the xvfb implementation, still runs flawlessly in headless mode with absolutely no timeouts despite repeated runs. When I try running it in headful mode, I consistently timeout on the puppeteer launch, even when I tried extending the timeout to 5 minutes. I've tried an absurd amount of launch-option combinations to no avail. Any and all help would be so greatly appreciated, even if it means significantly altering my approach to the problem. Thank you!
Related
I'm developing in ext.js and I'm seeing some really weird behavior.
We have 2 QA guys see a page one way while another developer and I see it another way. The actual markup of the page is slightly different.
We've done multiple screensharing sessions to confirm that we're doing everything the same as the QA guys. We have tried Edge, Chrome, and Firefox. We've both tried clearing browser cache, and even logging in with each other's credentials, but all of the browsers on my dev machine see the page with slightly different markup than the QA people.
This is when we're viewing a webpage that's running on a test server, not running on our local dev machines.
I'm wondering if that fact that the other developer and I have ext.js installed on our machines could mean that we're running a slightly different version of ext.js when we view the app that's running on the test server than what the 2 qa guys see.
Are you running the same build (dev/prod) command? Also, is it available as a npm application?
Where's the markup differ?
I've recently been working with Chrome's dev tools Performance tab to reduce the processing burdens of my page. I'm hoping to be able to append a check into my CI so that this isn't an exclusively manual process going forward.
Captures provide the following information:
This gives me the amount of time spent idle, and I know how long I've run the test for, so I can get %idle. I'd like to be able to run a headless process evaluating the page that ultimately allows me to determine %idle in the same way.
Is there a tool that can do this? I'd be happy to go as far as installing a headless chrome browser if there's a way to get this information in a report generated using command line arguments maybe?
As much as I adore Cypress it's starting to turn out quite badly. I don't think I would be doing something fundamentally wrong. I've read best practices a couple of times and I don't see what I could improve really.
It's starting to be rather frustrating. Having tests working perfectly on the local machine (tried running several times in the row) and yet when the same code runs through the CI (currently Bitbucket Pipelines), several tests fail for weird reasons.
For example, a single click on an item in the list adds a single item in the cart. Works perfectly however I try to break it and yet the same test in CI makes that click happen twice there for some reason. And that's one issue I am at least able to describe. Others are out of whack and very often happening just randomly like that element is no visible and yet looking at the screenshot I can see just fine.
I tried to use cypress-failed-log plugin to see command log, but that does not really help because it's the same thing I see locally and yet it fails in CI. A video I can see in Cypress Dashboard is not that helpful either because it's usually way too fast and some things are not even seen there.
Can someone advise me some other options on how to approach the issue at hand more gracefully? I must admit I am on the verge of giving up on these tests because it just takes too much time to make them reliable.
Some details about my setup:
cypress-failed-log#2.5.0
cypress-testing-library#3.0.1
cypress#3.3.1
# job definition for running E2E tests in parallel
e2e: &e2e
name: E2E tests
image: cypress/browsers:chrome67-ff57
caches:
- yarn
- home-cache
script:
- yarn -v
- cd cypress
- yarn install --frozen-lockfile
- npx #bahmutov/print-env BITBUCKET
- yarn ci --parallel --ci-build-id $BITBUCKET_BUILD_NUMBER
Weird, do you use the same browser when you do your local test ?
You use additional npm packages, maybe you could remove all the non essentials and retry ?
Cypress 3.3.0 claims to fix slow network requests. This could be relevant to CircleCI test failures.
In Cypress 3.1.4, #danielschwartz85 reported that they were seeing network slowness while making normal fetch requests. It was so bad that they reported load times of 5.5 seconds in Cypress, compared to 300ms in a regular browser - HTTP requests in Cypress were running up to 18 times slower than in Chrome for this test case.
A large part of Cypress is that it should behave just like a normal web browser, so this was a major issue. Users expect Cypress to "behave like Chrome", not "behave like Chrome but 18x slower". So, we set out to investigate the source of this slowness.
https://docs.cypress.io/guides/references/changelog.html
We use PhantomJs 2.0 to take screenshots of web pages. We've found that one particular page takes several minutes to process. This page does not appear to have this issue (or at least not of any comparable magnitude) when loaded in Chrome.
I believe that this is because the javascript is hanging/running very slowly. During the hang, Phantom is using a lot of CPU (although only one core). It does not appear to be taking up an abnormal amount of memory. I am fairly confident that javascript is the culprit because I can see from logging that all requests complete quickly, but then after the page loads Phantom hangs for awhile and won't run anything (I think this is because Phantom is all single-threaded so if the page is still running javascript my Phantom script won't run anything).
I'd like to debug and try to understand what part of the JS is taking so long, but I can't figure out how to get at this in Phantom. For example, I can't seem to collect any output from console.profile/console.profileEnd. How can I profile the javascript running in Phantom to find the bottleneck?
I use Phantomas, via grunt-phantomas. It's a tool that integrates with PhantomJS to profile a wide variety of performance-related metrics. Definitely worth checking out. If it doesn't give you exactly what you need, you can look at the source and see how they integrate with PhantomJS and get data out.
For a while I've been trying to run a JavaScript CPU profile of some applications I've developed, but everytime I start running the JavaScript CPU profiler in Chrome Dev tools, the application will stop responding at all (same as the profiler).
However, I noticed that this is not specific to my application, since I've been able to reproduce the same problem in other popular applications like Travis-CI.
I've been suspecting of extensions and plugins, but running without them doesn't seem to make a different -- the problem persists.
I've tested simpler apps with the same technology (the To-Do MVC example built in EmberJS) and that profile works just as fine.
I'm currently using Chrome 40.0.2214.111 m (64-bit).
Any idea on what the problem may be?
Update: I've tested both under incognito and guest browser mode. I thought the guest browser made a difference because I was able to profile my application once without problems. However, trying that again proved that the problem still persists.
Furthermore, I've found that the freezing time does not seem to be related with the application itself. Sometimes it'll hang when I focus an element, sometimes when I move around, some other times when I am in the middle of writing into a textbox. There seems to be nothing specific about the functionality of the app that's triggering this.
I've also tried disabling most extensions, without luck. I'll try disabling plugins as well and run as bare of a Chrome as possible.
Update 2: I've disabled all plugins and extensions completely, but the problem persists. I've also let the session go on to see if it eventually recovers. After around 2 hours, it was in the same situation. No bigger CPU consumption nor memory consumption, and other Chrome instances or tabs worked perfectly fine. I was able to close the developer tools but not interact with the original page anymore.
Update 3: I've just upgraded to Chrome 41 because it has been released in the stable branch, and I know it does include a few more things in the profiling section. I tried again and it didn't seem to make any difference.