Show JS errors in iframe during qunit testing within phantomjs - javascript

I am developing a cross-domain RPC library for which I want to do some unit-testing using qunit.
In order to do the testing properly I've setup a grunt file that launches a node.js server and phantomjs to load the test rpc.html as described here (using a server task so that different domains can be simulated, localhost and 127.0.0.1). This test opens an iframe with frame.html that mocks the RPC commands which are asserted within rpc.html.
So far all good. The problem I am encountering is that whenever a JS error occurs within frame.html it is not outputted to the console. Only errors that happen in rpc.html are shown. Although outputs of console.log() etc are working in frame.html.
Is there a way I can get all JavaScript errors to be shown that occur in frame.html, including parse errors and such?
Thank you in advance.

PhantomJS supports onError event handlers in its page objects, so that information about JavaScript exceptions can be intercepted and handled as appropriate.
AFAIK, you should possibly also check if loaded web-pages do not have their own window.onerror, because if they return true, the errors will be treated as handled.

Related

ReferenceError: document is not defined , nodejs does not understand DOM

Im trying to interact with a datamuse API using fetch()GET request and display it to the DOM.
But when i run node index.js im getting this error: ReferenceError: document is not defined.
const submitButton = document.querySelector('#submit');
i Googled it and got to know that nodejs does not understand DOM like how the browser does.
I tried fixing it:
with ESLint ,setting: env {browser: true}
installing JSdom package,then getting the error jsdom not defined
Could not figure ,please Help
Node.js is a completely different Javascript environment from the browser. It has a different library of functions available to it than the browser does. For example, the browser has the ability to parse HTML and present the DOM API and it has the window object. Node.js isn't browser at all so it doesn't have those features. Instead, it has TCP and HTTP networking, file system access, etc... the kinds of things you would typically use in a server implementation.
If, from node.js, you are trying to fetch a web page from some other server and then parse that HTML and then understand or manipulate the DOM elements in that web page, you would need a library for doing that. Libraries such as cheerio and puppeteer are popular tools for doing that. Cheerio, parses the HTML, but does not run the Javascript in the page and then offers a jQuery-like API for accessing the DOM. Puppeteer actually runs the chromium browser engine to parse the page and run the Javascript in the page to give you a fully representative DOM and can even do things like take screenshots of an actual rendered page.

XMLHTTPRequest Status 0 In Unusual Circumstances

I've been working on an AJAX script to perform some simple test manipulations via the Node.JS MongoDB driver. This script is causing me no end of headaches, for the following reasons:
When I run the script natively in the node.js command prompt, it runs to completion, and performs all of the operations I intend it to. A full trace of its activity in Chrome's Node Inspector reveals that it does indeed perform as intended.
Having debugged the script via Node Inspector, I then wrote a simple test page to call that script via AJAX. Despite taking care to use proper asynchronous callbacks, the script appears to hold up the server for an inordinate period of time, and returns with an HTTP status code of 0.
Having searched Stack Overflow for similar issues, the threads I surveyed all issue the same message - that this is a CORS problem. BUT ... if this was a CORS problem, NONE of the other AJAX scripts in the same directory would work, and would presumably return the same HTTP status code of 0.
Firing up a new, simpler test script to see if MongoDB connections are somehow interfering with my node.js server, this new script did NOT trigger an HTTP status code of 0, but instead returned as expected, with the HTTP status code of 200. This new test script resides in the same directory as the troublesome script, so it can't be a CORS issue.
Likewise, experimentally calling other scripts in the same directory via AJAX yields the same result - all the other scripts return HTTP 200 as expected.
So, why is this one script returning with an HTTP status of 0, while every other script in the same directory returns with an HTTP status of 200?
At this point, no doubt people will ask me to show the code. However, there's a slight problem. The script in question is 749 lines long, and I suspect that [1] it'll be impossible to pinpoint the error without embedding the entire code file in this question, and [2] numerous individuals will berate me for doing so. The fact that the script runs without errors in Node Inspector also makes this puzzling. I can edit this question and include all of that code if asked, but given what I've stated above, I have no idea where to begin pinpointing the error in that code, so there's no way I can select parts of it that might be problematic, especially in the light of the fact that it runs to completion, without error, in Node Inspector via the node.js command prompt.
Just in case this issue is platform specific, I'm running Node V8.11.3 LTS and MongoDB 4.0 on Windows 7 64-bit.

Overridden error handler inside iframe catches errors outside it (?!?)

The JavaScript single-page application I am maintaining opens most of the times in iframes created inside pages of our customers' sites.
Our SPA features a brutal override of window.onerror, as I want to be notified on my server of all JS errors happening during the execution of my code.
window.onerror = my_global_error_handler;
When JS code fails I record the domain where it came from. I'd expect that all errors be generated from code coming from my company's domain.
However, in some cases I get errors generated from JS code loaded from other domains. I wonder how this is possible, as I expect that my error handler be unable to catch errors outside the iframe where my code is executing.
Since most of the "foreign" domains mentioned in my logs are various viral e-marketing companies, I wonder whether some smart kid is managing to inject code in my iframe.
Another hypothesis is that some browsers may be overriding the top window's error handler when I override the one of the inner iframe window.
What could be happening?

Logging properties of Node.js

I'm starting on a project using Node.js, and I'm running into some issues with it's logging. I'm completely new to Node.js, but my understanding is that using console.log([data]) should print out the value of [data] to the server console.
I see this occurring how I expect in several places in this project, but when I try to add additional logging, nothing is prompted out to the console window.
I've noticed that all of the files where logging is working are under a specific folder, while the bulk of the code is under another.
Does anybody know what might be the cause of these not to print out into the console? I've also tried console.error([data]) and console.warning([data]) to see if it might be due to an error but that also didn't work.
Without having your actual code, this is just a guess:
The files where the logging is working are the Javascript files for the server. The "bulk" of the code may be the client code (I guess so because you're saying in the comments of your post that you inserted a working alert, which is a browser thing), so your logs go to the browser not to the server.

How to load fb all.js script on a Firefox addon

I am trying to load asynchronously the connect.facebook.net/en_US/all.js script , see here
The problem is that fbAsyncInit is never get called...
This is because 'window' in a content script is not the real window, but a proxy. I can get your code working by replacing window with 'unsafeWindow':
https://builder.addons.mozilla.org/package/157253/latest/
Note that this introduces a possible security issue - in particular you should not trust any data that comes form unsafeWindow or anything attached to it. This is a hack that can be used to get things working in cases where the the proxy will not, but could be used to allow web pages to execute arbitrary code with the privileges of the browser.

Categories

Resources