How do I change the underlying Phantomjs object settings using Chutzpah? - javascript

We have some QUnit javascript tests running in Visual Studio using the Chutzpah test adapter. Everything was working fine until we changed our api (the one being tested by the js files) recently, and added some validations over the UserAgent http header. When I tried to update the tests to change/mock the user agent I realized it was not directly possible even by overriding the default browser property.
After a few days of scavenging, I finally found what exactly is happening. Chutzpah is creating a phantomjs page object for the test files to run on. This is being done on a base javascript file (chutzpahRunner.js) located at the Chutzpah adapter installation path. These are the last lines on the file, that effectively start the tests:
...
// Allows local files to make ajax calls to remote urls
page.settings.localToRemoteUrlAccessEnabled = true; //(default false)
// Stops all security (for example you can access content in other domain IFrames)
page.settings.webSecurityEnabled = false; //(default true)
page.open(testFile, pageOpenHandler);
...
Phatomjs supports changing the user agent header by specifying it in the page settings object. If I edit this chutzpahRunner.js file in my machine, and manually set the user agent there, like this:
page.settings.userAgent = "MyCustomUserAgent";
My tests start to work again. The problem is that this is not in the project itself, and thus cannot be shared with the rest of the team.
Is it possible to change the properties of the phantomjs objects created by Chutzpah to run the tests? I'd like to either change them from inside my own tests, or from another script file I could embed on the pipeline.

Without a code change in Chutzpah it is not possible to set those properties on the PhantomJS object. Please file an issue at https://github.com/mmanela/chutzpah asking for this functionality and then fork/patch Chutzpah to add it (or wait for a developer on the project to hopefully get to this).
Update:
I pushed a fix for this issue. Once this is released you can use the following in a Chutzpah.json file:
{
"userAgent": "myUserAgent"
}

Related

Why don't web workers work?

So, I'm trying to use a web worker in my project to run a long-running process that is currently tying up the UI. I've been to I don't know how many sites trying to get a worker to work, but to no avail.
All of my javascript is kept in separate files and referenced in the HTML file. As a test to get my feet wet, I created a test.js file and put the following code in it:
self.addEventListener('message', function(e) {
self.postMessage('return');},false);
Then, in the UI page's javascript file I placed this code in a function triggered by a button click event:
var w = new Worker('test.js');
w.addEventListener('message',function(e){
alert(e.data);},false);
w.postMessage('hi');
The code is derived from:
html5rocks.com/en/tutorials/workers/basics
Other websites I visited provided similar instructions on how to set up a worker.
For the life of me, I cannot get this to work. When I execute it does absolutely nothing and I seemingly get no errors. Stepping through the code, it appears to create the worker, but I don't see any evidence of the event listener being created and the 'postMessage' event doesn't do anything. I've tried IE11 and Chrome with the same results.
In my research, I came across a part of Chrome's developer tools that revealed the test.js file couldn't be found. Yet, the file is in the same folder as the page's js file. So, I tried adding in the relative directory information as I do in the page's HTML section. That didn't work either.
I then found claims that for security reasons you couldn't have one js file reference another js in the code. It's unclear whether this is a Chrome-only feature or part of some spec.
So, now I'm in a quandary. The worker requires a reference to a separate js file for the code to be executed, yet, the browser isn't allowed to reference another file? How is the worker supposed to work if you aren't allowed to do what it requires to work?
To now, I've successfully pissed away two days trying to get this one seemingly simple function to work. To say I'm mildly frustrated would be an understatement. Being a fairly novice programmer and not understanding every last little nuance about web programming I'm clearly missing a key part of this whole thing.
How the heck is one supposed to make web workers work?
Turns out browsers won't allow local files to be fetched via javascript. Because that means a website can read your personal files! So you need to develop and test your project using a web server. The easiest way to do this for me was to install:
docker-compose
and make sure it works. Then create a file named:
docker-compose.yml
inside root folder of my project with index.html file. Then put this inside the docker-compose.yml file:
version: '3'
services:
nginx:
image: nginx:alpine
volumes:
- .:/usr/share/nginx/html
ports:
- "80:80"
Then inside the root folder of my project run:
docker-compose up
And then in the browser go to:
http://localhost/
And it worked!
I appear to have found a solution, though it escapes me why.
If I use:
var w = new Worker('js\test.js');
the worker doesn't work.
But, if I use:
var w = new Worker('js/test.js');
the worker does work.
I characteristically use the back slash throughout the project to delineate paths without issue. Why the forward slash must be used to set the worker's file location is a mystery. I have seen nothing in any documentation that even remotely addresses that tiny, yet seemingly critical detail.
Thank you, Mr. Starke, for your help!

Breakpoints in WebStorm not hitting for JavaScript debugging

I have the following configuration setup in WebStorm:
When I click debug, it launches Chrome fine and navigates to the page, but my breakpoints never get hit. It's connected somehow though because I see all of the console.log() output in WebStorm.
I'm trying to navigate to the URL specified in the screenshot and have breakpoints in main.js get hit, but it doesn't work as expected (see: at all). I'm not exactly sure what I'm missing. I've tried setting a remote URL for the specific main.js file in the Remote URLs section, but that didn't help either.
For reference I run the application via bra run and npm run watch.
Quick Update
So I've been able to actually get a breakpoint to hit, but it's in a different file (in a different path):
../public/app/core/routes/dashboard_loaders.ts allows me to stop at breakpoints, but ../public/dashboards doesn't.
When I navigate to http://localhost:3000/dashboard/script/main.js?orgId=1, it hits the route:
.when('/dashboard/:type/:slug', {
templateUrl: 'public/app/partials/dashboard.html',
controller : 'LoadDashboardCtrl',
reloadOnSearch: false,
pageClass: 'page-dashboard',
})
Which ultimately does load the file ../public/dashboards/multi.js -- but no breakpoints are hit.
Further Updates
It looks like the script is served via the following command (in ../public/app/features/dashboard/dashboardLoaderSrv.js):
/*jshint -W054 */
var script_func = new Function('ARGS','kbn','dateMath','_','moment','window','document','$','jQuery', 'services', result.data);
var script_result = script_func($routeParams, kbn, dateMath, _ , moment, window, document, $, $, services);
Where $routeParams are type:script and slug:main.js - If I step into this function, I get an anonymous(?) file that's identical to my actual main.js file, but the name is like 43550 instead of main.js -- I think this is boiling down to a fundamental lack of knowledge in how JavaScript handles something on my part. :)
Edit: I found this issue for using webstorm with grafana (second edit) looks like this is you.
I think what he linked solves it with declaring a sourceUrl then your file isn't "anonymous" or rather dynamic.
//# sourceURL=filename.js
I.E
//# sourceURL=main.js
Reference How to debug dynamically loaded JavaScript (with jQuery) in the browser's debugger itself?
Here is the documentation and video on debugging in webstorm to make sure everything is setup properly. (I.E My default setting were to debug my index file instead of my project). Make sure you have their Chrome extension or Firefox Extension
General JS Debugging in Webstorm
Debugging for Chrome in Webstorm
Debugging for Firefox in Webstorm
Debugging Node.JS in Webstorm

selenium + chrome.fileSystem.chooseEntry = invalid calling page error

I am writing a Selenium script to test a Chrome app that uses the Chrome.fileSystem.chooseEntry API to select a directory. When I do this manually, it works fine. But when I do this in a Selenium script, I get back this error:
Unchecked runtime.lastError while running fileSystem.chooseEntry: Invalid calling page. This function can't be called from a background page.
Any ideas on how to make Selenium and chooseEntry play nicely together?
I updated to the latest Chromedriver, but still no luck. I also looked at ChromeOptions, but didn't see anything that looked like it would be helpful. The interwebs doesn't seem to have much to say about Selenium and chooseEntry. I'm on version 51 of Chrome.
I'm down to thinking I'll need a special javascript entry point to set the path values for testing instead of using chooseEntry. But I would strongly prefer to not have a separate code execution path for my tests. Anybody have a cleaner solution?
EDIT: per commenter's request, here's the offending code:
chrome.fileSystem.chooseEntry({type:'openDirectory'},function(entry) {
chrome.fileSystem.getWritableEntry(entry,function(writeable_entry) {
console.log("got writeable entry");
});
}, function(e) { errorHandler(e); });
EDIT #2: I've gone with the special javascript entry point hack. In manual mode -- i.e., not running under Selenium -- I run code that executes chooseEntry, and then use the retainEntry API to get the entry id. I added an entry point in my javascript to take an entry id and call the restoreEntry API to turn it back into an entry. I also modified my code so if this entry object is set, then use that as the file instead of calling chooseEntry. Lastly, I modified my Selenium script to call the restoreEntry entry point before running the rest of the script.
This is not ideal, since now my test code execution path is somewhat different from my actual live-human-being-at-the-controls code execution path. But at least it lets me use Selenium scripts now. Of course, if anyone can think of a non-horrible way to solve this solution, I'd love to hear about it.
EDIT #3: Per #Xan's comment, corrected my terminology from "extension" to "Chrome App."
I can only offer this horrible hack. For Chrome Apps under OSX I created folder favorites and use Robot keyPress to navigate and select the 'favorite' folders needed for the App. The only possible redeeming factor is that it does mirror a valid/possible actual human interaction with the file interface.
private void selectOSXFolderFavorite(int favorite) {
// With an OSX file folder dialog open, Shift-Tab to favorites list
robot.keyPress(KeyEvent.VK_SHIFT);
robot.keyPress(KeyEvent.VK_TAB);
robot.keyRelease(KeyEvent.VK_TAB);
robot.keyRelease(KeyEvent.VK_SHIFT);
// move to the top of favorites list
int i = 40;
while (i-- > 0) {
robot.keyPress(KeyEvent.VK_UP);
robot.keyRelease(KeyEvent.VK_UP);
}
while (favorite-- > 0) {
robot.keyPress(KeyEvent.VK_DOWN);
robot.keyRelease(KeyEvent.VK_DOWN);
}
// Send an enter key to Select the selected folder
robot.keyPress(KeyEvent.VK_ENTER);
robot.keyRelease(KeyEvent.VK_ENTER);
}

How to run Dojo DOH unit-tests through Jenkins?

Has anyone tried integrating Dojo DOH unit-tests with Jenkins?
I'd like to do the following, but don't want to reinvent it if this has already been done. So, I'm thinking:
Kick off the DOH-tests from a post-build step in Jenkins and wait for the results
Run the tests themselves in a headless-browser (e.g. Crowbar)
Parse the succes/error-count from the HTML returned by Crowbar
Find (or write) a Jenkins plugin that will (a) fail the build if there are failing tests, (b) render the test results, (c) possibly integrate results into the CI game plugin
Questions:
Has this been done before?
Do you see any issues with the outline above?
Do you know of a Jenkins plugin that will help, or will I have to build my own?
1. Automated Dojo testing - DOH & Selenium-RC (Rob Coup - 2008/01/03)
Plan:
Have a config file defining which browsers to launch, which machines they're on, and what tests to run.
Launch each browser via Selenium-RC
Run the tests via the normal DOH browser runner.
Use Selenium to extract the results from DOH.
Collate the results from the various browsers and produce something useful.
Solution:
Drop seleniumRunner.js, seleniumRunner.config.js, seleniumRunner.sh (or the .bat if you're on Windows), and selenium-java-client-driver.jar into util/doh/ in your Dojo install.
Put selenium-server.jar on each test machine, then run java -jar selenium-server.jar -multiWindow so it listens for the browser-control messages.
Edit seleniumRunner.config.js and change browsers and rootUrl to match your setup. The rootUrl needs to be reachable from each test machine.
run ./seleniumRunner.sh seleniumRunner.config.js from util/doh/ on your workstation
It'll load the config, fire up the browsers on each machine, run the unit tests from Dojo core, and print the pass/fail/error stats for each.
Each browser is kicked off and monitored in a separate thread (not strictly necessary but too cool to resist doing).
Issues:
unless I ran the selenium server in multiWindow mode Safari and Firefox would pop up Print dialogs (!?!) whenever the test page was
loaded. But Safari never initialised the test page if it was in
multiWindow mode. On OSX and Windows. gah.
Opera on OSX didn't set up the Selenium proxy properly (localhost:4444 for reference).
IE didn't like doing a dojo.connect() via the selenium javascript commands for some reason.
2. Seems reasonable to me.
3. Jenkins Selenium plugin
This plugin turns your Jenkins cluster into a Selenium2 Grid cluster,
so that you can utilize your heterogeneous Jenkins clusters to carry
out Selenium tests. This plugin is a turn-key solution — no additional
installation nor configuration is necessary to make it work. The
plugin installs Selenium Grid on all the slaves automatically and set
up a grid on its own.
For running the D.O.H tests i have developed a tool which integrates into ci and can start the browser.
http://codeblog.bigbrowser.net/dojo-testing-d-o-h-with-continuous-integration/
Maybee you can give this also a try.
I have explained there where to download and how to run it.
Here's how I did it with HTMLUnit. No Selenium required.
It runs as a regular JUnit test (which can easily be run automatically by your CI Server), and prints out the DOH log if there is a test failure.
public class JavascriptTest {
private static final int MAX_RUNNING_TIME = 10 * 1000;
//The test runner
public static final String PATHNAME = "src/main/webapp/library/mystuff/dojo/util/tests/runTests.html";
//Runs all of the Dojo Objective Harness (D.O.H.) javascript tests.
//The tests are currently grouped into test modules, and the parent module is "util.tests.module" (in module.js)
//As you can see in the URL pathname, we pass that module name to the testRunner and it runs all the javascript tests.
#Test
public void runAllJavascriptTests() throws Exception {
final WebClient webClient = new WebClient(BrowserVersion.INTERNET_EXPLORER_8);
final HtmlPage page = webClient.getPage("file://" + new File(PATHNAME).getAbsolutePath());
waitForTestsToRun(webClient, page);
String log = page.getElementById("logBody").asText();
assertTrue(log, page.asText().contains("WOOHOO!!")); //D.O.H. will display WOOHOO!! if all tests are successful.
}
private void waitForTestsToRun(WebClient webClient, HtmlPage page) {
webClient.waitForBackgroundJavaScript(500);
int runningTime = 0;
while(testsAreRunning(page) && runningTime < MAX_RUNNING_TIME){
webClient.waitForBackgroundJavaScript(500);
runningTime += 500;
}
}
private boolean testsAreRunning(HtmlPage page) {
//Check if the "Tests Running" div is visible.
return "".equals(page.getElementById("playingMsg").getAttribute("style"));
}
}
And below is the content of runTests.html. It basically just redirects to the DOJO test runner, with parameters specific to the tests in the directory we want to test.
It's just a nice way to structure things, you could alternatively have specified this URL in the PATHNAME field in the JUnit test.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Dojox Unit Test Runner</title>
<!--The "testModule" param tells the runner which test module to run-->
<!--The "paths" param adds our dojo module paths, otherwise it would just look in the default dojo modules for code to test.-->
<meta http-equiv="REFRESH" content="0;url=../../../../dojo-release-1.7.2-src/util/doh/runner.html?testModule=util.tests.module&paths=util,../../mystuff/dojo/util;mystuff,../../mystuff/dojo"></HEAD>
<BODY>
Redirecting to D.O.H runner.
</BODY>
</HTML>

Visual Studio 2008 jQuery IntelliSense sporadically fails, restarting VS fixes

Right off the bat, this is not your standard "I can't get javascript IntelliSense to work in Visual Studio." For the record:
I'm using Visual Studio 2008
I have installed SP 1
I have installed the hotfix for -vsdoc.js documentation files KB958502
I am developing a suite of interrelated jQuery plugins to be packaged as resources in a class library. So within a directory, I have (as an example):
jquery-vsdoc.js
core.js
plug1.js
plug2.js
In core.js, I have the following at the top of the file:
/// <reference path="jquery-vsdoc.js" />
Then in each of the plug#.js, I have:
/// <reference path="jquery-vsdoc.js" />
/// <reference path="core.js" />
The IntelliSense works initially, even including the additions from core.js when working in the plugins. However, sometimes the slightest change, even adding and removing a space from the reference XML tags, or pressing Ctrl-Shift-J, results in the dreaded "Error updating JScript IntelliSense: Client-side script IntelliSense information was not generated due to an error in an external script reference." Except it was working with that external script reference just a second ago!
For the jquery-vsdoc.js, I am using Comment Version 1.3.2b (that's what it says in the file) from http://jqueryjs.googlecode.com/files/jquery-1.3.2-vsdoc2.js. I am omitting the version number from the file so that I don't have to change a bunch of references when it's inevitably updated.
So what could be the problem? Restarting Visual Studio is proving to be a horribly inelegant (and time-consuming) workaround.
Have you tried increasing the IntelliSense timeout?
By default, every IntelliSense request
is only allowed 15s to execute. This
is to prevent IntelliSense from
scripts with infinite loops. If you
have a large script or slower machine,
it may make sense to increase the
timeout limit. The timeout value
store within following registry keys
(depending on if your are using
Express or the full product). The
value is in milliseconds so choose
something greater than 15000.
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\HTML
Editor\JsFailsafeTimeout
HKEY_CURRENT_USER\Software\Microsoft\VWDExpress\9.0\HTML
Editor\JsFailsafeTimeout
Does closing and opening the file reset the state?
Open the task manager and watch the processes. Do you see a process called "typelibbuilder.exe" get started when you press Ctrl-Shift-J?
I'm trying to image what sort of problems might require a restart of VS. The processing of references (to which that message pertains) is done in a new and separate process every time you press Ctrl-Shift-J (unless processing has been disabled in which case you would see a different message). It almost sounds like the communication between VS and typelibbuilder or some other necessary component is failing.
In SP1, you shouldn't need to reference the "-vsdoc" files directly. If you reference "foo.js" and there is a "foo-vsdoc.js" file next to it, then VS will use the vsdoc version to generate intellisense. I doubt that is related to your problem though.
I know this isn't much consolation, but we've drastically improved performance and reliability of Javascript Intellisense in Visual Studio 2010. Beta1 is currently available to MSDN subscribers (although it is beta and there are still some bugs in it).
If you can get reliable repro steps, you could also file a bug report at http://connect.microsoft.com/.
I dont know if this will help you, but I've encountered the following bug in VS 2008 JS intellisense:
When adding jQuery as a reference in an external file, and then I update JS I get:
'XmlHttpRequest is undefined' on the line:
return window.ActiveXObject ? new ActiveXObject("Microsoft.XMLHTTP") : new XMLHttpRequest();
It seems like the JS intellisense engine is actually executing some of the jQuery code (more than likely to inspect it so it can provide some more information about it). However it looks like window.ActiveXObject is null to the engine, and so it falls into the 'new XMLHttpRequest()' block - which also fails.
I hacked a workaround that breaks all browsers except IE - so not a good solution. My fix changes the following:
xhr: function()
{
// hack to fix VS 2008 intellisense... note this breaks any browser
// except IE
var objXhr = { open: function() { },
setRequestHeader: function() { }
};
return window.ActiveXObject ? new ActiveXObject("Microsoft.XMLHTTP") : objXhr;
},
Now my intellisense works.
You may want to disable JavaScript intellisense in Visual Studio.
When SP1 is installed you can disable JavaScript intellisense.
Go to Tools, Options...
The Options dialog will show up.
Navigate to the following node in the left hand sided panel:
Text Editor :: JScript :: General
Disable the following options (in the group Statement Completion):
* Auto list members
* Parameter information

Categories