I'm trying to capture a website using PhantomJS, in particupar I'm using Pageres.
This website has got:
AngularJS
LocalStorage use
AJAX requests to an API
So, I'm testing locally and I'm not getting expected results, sometimes the screenshot will work with errors -rendering part of the contents, sometimes it won't render complete contents.
It really looks like Pagerer gets not enough time to take the screenshot once the site has fully loaded. I already added delay option but it will fail anyways, actually I could said it has worked better with out the delay option.
This is what it should be rendered:
And when it has worked best, this is what I get:
This is my code for rendering:
var pageres = new Pageres({})
.src('fantastica.a2015.mediotiempo.com', ['1440x900'], {delay: 3, crop: false});
pageres.on('warn', function (err,obj) {console.log(err,obj)});
pageres.run(function (err, screenshot) {
screenshot[0].pipe(response);
});
And, (I know there would be MUCH code to explain now) this is JS code being rendered.
Any particular advice?
Be aware of the differences between Phantom versions.
Phantom 1.9.x (which Pageres is using) is a browser engine from quite a few years ago (Chrome 13 is the closest equivalent) and will not render many HTML5 features.
Phantom 2.x is a much more modern webkit engine. But because of: a) because they have not produced a ready-made linux binary; b) some small API changes, projects like CasperJS and Pageres are holding back on supporting it. According a comment in https://github.com/sindresorhus/pageres/issues/77 if you make your own binary, and symlink to it, it works.
Also be aware that SlimerJS is an alternative to PhantomJS, based on Firefox rather than WebKit. There is no similar project based on Blink (to get screenshots how a modern Chrome would render them), but there is TrifleJS for IE. (However the Pageres pages say it is not the goal of the project to support other engines.)
Wait for DOM elements to appear, rather than using a delay.
Ajax calls, delayed loading, etc. make things very hard to predict. So, enter a polling loop, and don't take your screenshot until the DOM element you want in your screenshot is now visible. CasperJS has waitForSelector() for this case. PhantomJS has the slightly lower-level waitFor().
I think pageres would need a bit of hacking to add this functionality.
Related
We have a reactJs application which works fine on all other browsers except safari on macOS and ios. The app works perfectly on Chrome on macOs or windows and ios as well.
Also, once the app freezes, we cannot open dev console in safari and if it is open, most of the things don't work like pausing script execution. And we can say from activity monitor that it goes in some infinite loop as the cpu usage of that page goes to 100% but i am unable to figure out as there are no errors at all and it works on other browsers.
It just freezes on loading and becomes totally unresponsive (No scroll or clicks etc). It looks like there is some infinite loop or dependency issue.
The webapp is kind of LMS and has many dependencies but to give you an idea here is the stack -
GraphQL
React Router Dom
React Hooks
Sentry for Logging
Socket
etc
If you have any questions feel free to ask.
Here is the site - https://i3.stage.cudy.co/
Thanks
I went into trying to see what's going on and I noticed three things:
First couple of times I tried to open your site it froze as you say. Could not even open dev tools.
After previous tries, I suddenly saw the icons for your menu options (browse tutors, assignments, feeds, etc) appear and everything worked "fine" and no more freezes.
However, I did noticed a bunch of errors in dev tools. Most of them are related to urls not allowed to access and some others due a /profiles trying to access an API of some sort.
You have a lot of unhandled promise rejections errors in your *.js so that may also be something to look at.
I would suggest tackling down the cross domain origin policies first and then add logic to handle the promise rejections that you're missing since sometimes those unhandled scenarios leave the app at the dark without knowing what to do and may interrupt your logic process thus rendering frozen sites because of that.
Last but not less important, this is a good way of tracing down the issue.
There are way too many factors involved for us to help you without looking at the code.
I'd recommend the following:
Going through the code history and testing it on each major version change so you can rule out any culprits or suspicions.
I'd disconnect any packages 1 by 1.
Disconnect the API so see if it's a server issue where you're requesting API calls infinitely or something silly like that.
If disconnecting the API works then you know where to look at.
Cheers
When developing my react app the app becomes unusably slow with the devtools open in chrome. Works fast and fine with them closed or in incognito mode. I have tried disabling all extensions and had the same problem. This seems to have started happening recently when I updated chrome (now on Version 80.0.3987.132).
I am not really sure where to start debugging this issue but it has become very frustrating to develop on my app.
Any advice or help debugging would be appreciated.
TL;DR: Go to the Sources tab and delete all breakpoints for the site.
I had a similar problem. My site was very slow to load, but only in specific circumstances:
Dev-tools were open.
Tab was in a normal window. (not incognito mode)
Profiling was not enabled.
If (and only if) all three of those conditions were met, the site would load unbearably slowly (15+ seconds; normally ~3s), plus have performance issues for certain operations on the site (like changing which subpanel was open). It was very strange.
Like you, I tried disabling all of my extensions, yet the problem persisted.
Attempt 1: I tried clearing all of the site's cookies and local-storage, using the info/lock dropdown at the left of the address-bar. Suprisingly, that seems to have fixed it! (edit: this was not the root problem; see below for that)
So the problem must be that my site was storing too much data in local storage or something, such that dev-tools was choking on it (but only in specific cases, for some reason). This also matches with the issue resolving in incognito mode: incognito mode uses a "clear slate" for site cookies/local-storage.
Anyway, it's an odd one, but the cookies/local-storage clearing seems to have worked for my case. (If the issue comes up again, and the solution above doesn't fix it, I'll try to remember to mention it.)
Update: Oddly, having the profiler on still speeds things up even after the fix (ie. those three conditions being met still slows down page loading and actions, just much less than before the fix). So apparently the fix merely "reduces the intensity" of the problem rather than fully fixing it; like, by resetting local-storage, it lessens the size of that data, which somehow is a variable affecting the core problem (not yet identified).
Attempt 2: I believe I have found the root problem and solution: I removed all breakpoints for the site, and the slowdown was solved completely. So the problem seems to be that I had lots of unneeded breakpoints set at various places in my website code (some enabled, some disabled). Some of these must have been placed in/near "hotspots" that were getting called frequently. By having the dev-tools open, the Javascript engine must have had to start performing some processing related to the breakpoints, slowing things down.
My guess is that the problem would also be fixed by disabling the "JavaScript source maps" settings (as that's the only thing I can think would cause so much slowdown), but I haven't confirmed this.
This has most probably something to do with this commit, titled "Stop sending profile data when recording is off".
They already know there is an issue with the Developer Tools slowing down and they tried to prevent it by preventing profiling data to be sent via the bridge to the frontend, when not recording.
As reported, it seems the issue is not happening anymore, on the latest version. However, the cause is still unknown.
Try uninstalling the Developer Tools extension, clearing browser cache and then installing it again.
You should probably try using a version other than the one you're using, Version 80.0.3987.132. The app you are trying to develop might not be suitable to the version you are using. Delete the extension you are using, clear and remove every trace of browser cache and then re-download the extension, like what Daniele Molinari said. It might help. If it doesn't let me know. I'll try a different approach.
This is a weird one I've only recently noticed since Chrome 60.0.3112.90 on Mac OS X 10.11.6, and it really impacts my daily work.
Chrome is creating a new console context every time an Angular application is reloaded, and the previous instances (presumably) stick around. This makes working in the console difficult because the context of the console sometimes remains on an old context. Whats worse is you cannot even interact with an old context so why does it remain?
I'm unsure if this is a UI bug or an actual issue with the Angular application possibly keeping reference to something from the previous context (not sure how or what would even do that).
This occurs on both the product I work on, and on the Angular documentation website.
Here's a gif of it happening:
http://i.imgur.com/lVjLJnu.gifv
Every time you see me click outside of the console, I'm performing a reload.
Any ideas? This is absolutely obnoxious. I've disabled all extensions with no difference. My colleagues on Linux do not have this problem.
Background:
I have built a tool using angularjs. The user is able to view a dynamic page based on the data. The page can be really long with lots of various types of fields within it. There are many and various angularjs components used within the app.
Issue:
If a user has got lots of data (which is shown within various input fieds/date fields etc; around 500 fields ) then the page takes around 3 minutes to load in IE browser (IE11 is my browser). The same page loads within 20 seconds on chrome and firefox. I have tried now almost a month to find the issue ..but still no luck.
I am very desperate for a solution. I coudn't find any tool that would show me what is causing my page to take so long to load.
Well, first things first, you'll need to profile what is actually taking so long. I suggest you check out
https://github.com/angular/batarang
to do this. A good article that goes over it's use is available at http://daginge.com/technology/2013/08/11/debugging-performance-problems-in-angularjs-with-batarang/ -
It's too long to include in this answer, but the general flow of resolving this is probably going to involve streamlining the watchers involved in each of those component fields etc - rendering 500 fields at once seems somewhat unnecessary - pagination would probably be an easy fix. Limit the data to maybe 50 fields per page? You'll need to track if it's the actual queries you're running to get the data that is taking so long, although based on the difference betweeen IE and Chrome, I would guess it's going to be something in the browser. It could also be that IE is being forced to use some polyfills for the functionality that Chrome and FF are supplying natively. Maybe link to your repo for us to have a look at?
I'm attempting to write some UI tests for a RequireJS-based Backbone application, utilizing FluentAutomation.SeleniumWebDriver and NUnit. The HTML page in question contains a typical data-main attribute for loading the RequireJS module for the application. My struggle is in properly detecting when the application is fully loaded with these tools; the only thing I've gotten to work consistently so far is using an explicit wait in seconds, like so:
I.Open("http://myapp")
.Wait(5)
.Enter("foo").In("input[name=username]")
.Enter("bar").In("input[name=password]")
.Click("button")
.Wait(5)
.Expect.Text("Welcome").In("#welcome");
This is less than ideal -- my test as written above will always take at least 10 seconds to run, when in reality the app might be "ready" much faster than that. What I'd like to be able to do is something like this:
I.Open("http://myapp")
.WaitUntil(() => I.Assert.Exists("input[name=username]"))
.Enter("foo").In("input[name=username]")
.Enter("bar").In("input[name=password]")
.Click("button")
.WaitUntil(() => I.Assert.Exists("#welcome"))
.Expect.Text("Welcome").In("#welcome");
However, this doesn't work -- using WaitUntil here actually seems to prevent the app from loading, for reasons unclear to me, as I simply receive timeout exceptions after the default wait period (30 seconds), stating that it was unable to locate the element in question within that timeframe.
I see that Selenium 2 provides a WebDriverWait for this kind of scenario, and possibly that would work here, but am unsure how I would use this within FluentAutomation (and a quick search of the FluentAutomation code on GitHub doesn't seem to indicate it's in use within the library).
What can I use in FluentAutomation to properly wait for a RequireJS module (or DOM loaded by it) to be ready?
Additional details:
This might not be a RequireJS compatibility problem at all. I've looked further into the app and found that what's happening after the Click("button") is actually a window.location.replace -- not a RequireJS async module load. It's the one place in the app that this is occurring, apparently. So, is a window.location redirect a known scenario that would cause problems with WaitUntil, and is there an alternate approach (aside from a simple Wait(5)) that would properly handle this?