Current Dev State

static/js/ketcher2/node_modules/webdriverio/docs/api.md

@@ -0,0 +1,66 @@
+layout: api
+name: api
+title: WebdriverIO - API Docs
+---
+
+# WebdriverIO API Docs
+
+Welcome to the WebdriverIO docs page. These pages contain reference materials for all implemented selenium bindings and commands. WebdriverIO has all [JSONWire protocol](https://github.com/SeleniumHQ/selenium/wiki/JsonWireProtocol) commands implemented and also supports special bindings for [Appium](http://appium.io).
+
+## Examples
+
+Each command documentation usually comes with an example that demonstrates the usage of it using WebdriverIO's testrunner running its commands synchronously. If you run WebdriverIO in standalone mode you still can use all commands but need to make sure that the execution order is handled properly by chaining the commands and resolving the promise chain. So instead of assigning the value directly to a variable, as the wdio testrunner allows it:
+
+```js
+it('can handle commands synchronously', function () {
+    var value = browser.getValue('#input');
+    console.log(value); // outputs: some value
+});
+```
+
+you need return the command promise so it gets resolved properly as well as access the value when the promise got resolve:
+
+```js
+it('handles commands as promises', function () {
+    return browser.getValue('#input').then(function (value) {
+        console.log(value); // outputs: some value
+    });
+});
+```
+
+Of course you can use Node.JS latest [async/await](https://github.com/yortus/asyncawait) functionality to bring synchronous syntax into your testflow like:
+
+```js
+it('can handle commands using async/await', async function () {
+    var value = await browser.getValue('#input');
+    console.log(value); // outputs: some value
+});
+```
+
+However it is recommended to use the testrunner to scale up your test suite as it comes with a lot of useful add ons like the [Sauce Service](http://webdriver.io/guide/services/sauce.html) that helps you to avoid writing a lot of boilerplate code by yourself.
+
+## Element as first citizen
+
+To make the code more readable and easier to write we handle element calls as first citizen objects. This means that if you call the [`element`](/api/protocol/element.html) to query an element, WebdriverIO propagates its prototype to the result so you can chain another command to it. This is useful when writing tests with the [Page Object Pattern](http://martinfowler.com/bliki/PageObject.html) where you want to store your page elements in a page object to access them in the test. Simplified this can look like:
+
+```js
+it('should use elements as first citizen', function () {
+    var input = browser.element('.someInput');
+
+    input.setValue('some text');
+    // is the same as calling
+    browser.setValue('.someInput', 'some text');
+});
+```
+
+Each command that takes a selector as first argument can be executed without passing along the selector again and again. This not only looks nice, it also avoids querying the same element over and over again. The same works in standalone mode:
+
+```js
+it('should use elements as first citizen in standalone mode', function () {
+    return browser.element('.someInput').setValue('some text');
+});
+```
+
+## Contribute
+
+If you feel like you have a good example for a command, don't hesitate to open a PR and submit it. Just click on the orange button on the top right with the label _"Improve this doc"_. Make sure you understand the way we write these docs by checking the [Contribute](/contribute.html) section.

static/js/ketcher2/node_modules/webdriverio/docs/guide.md

@@ -0,0 +1,162 @@
+layout: guide
+name: guide
+title: WebdriverIO - Developer Guide
+---
+
+# Developer Guide
+
+Welcome to the WebdriverIO documentation. It will help you to get started fast. If you run into problems you can find help and answers on our [Gitter Channel](https://gitter.im/webdriverio/webdriverio) or you can hit me on [Twitter](https://twitter.com/webdriverio). Also, if you encounter problems in starting up the server or running the tests after following this tutorial, ensure that the server and the geckodriver are listed in your project directory. If not, re-download them per steps 2 and 3 below.
+
+The following will give you a short step by step introduction to get your first WebdriverIO script up and running.
+
+## Taking the first step
+
+Let's suppose you have [Node.js](http://nodejs.org/) and Java already installed. First thing we need to do is to start a selenium server that executes all selenium commands within the browser. To do so we create an example folder first:
+
+** 1. Create a simple test folder**
+```sh
+$ mkdir webdriverio-test && cd webdriverio-test
+```
+
+*While still in this test folder:*
+
+Then let's download the latest [selenium standalone server](http://docs.seleniumhq.org/download/) version:
+
+** 2. Download latest selenium standalone server**
+```sh
+$ curl -O http://selenium-release.storage.googleapis.com/3.0/selenium-server-standalone-3.0.1.jar
+```
+
+** 3. Download the latest version geckodriver for your environment and unpack it in your project directory**
+
+Linux 64 bit
+
+```sh
+$ curl -L https://github.com/mozilla/geckodriver/releases/download/v0.11.1/geckodriver-v0.11.1-linux64.tar.gz | tar xz
+```
+
+OSX
+
+```sh
+$ curl -L https://github.com/mozilla/geckodriver/releases/download/v0.11.1/geckodriver-v0.11.1-macos.tar.gz | tar xz
+```
+
+Note: Other geckodriver releases are available [here](https://github.com/mozilla/geckodriver/releases).
+
+Start the server by executing the following:
+
+** 4. Start selenium standalone server**
+```sh
+$ java -jar -Dwebdriver.gecko.driver=./geckodriver selenium-server-standalone-3.0.1.jar
+```
+
+Note that this command sets webdriver path variable so that Selenium uses the geckdriver binary that was added to the project directory and also starts Selenium standalone server.
+
+Keep this running in the background and open a new terminal window. Next step is to download WebdriverIO via NPM:
+
+** 5. Download WebdriverIO**
+```sh
+$ npm install webdriverio
+```
+
+** 6. Create a test file (test.js) with the following content**
+```js
+var webdriverio = require('webdriverio');
+var options = {
+    desiredCapabilities: {
+        browserName: 'firefox'
+    }
+};
+
+webdriverio
+    .remote(options)
+    .init()
+    .url('http://www.google.com')
+    .getTitle().then(function(title) {
+        console.log('Title was: ' + title);
+    })
+    .end();
+```
+
+** 7. Run your test file**
+```sh
+$ node test.js
+```
+
+this should output the following:
+
+```sh
+Title was: Google
+```
+
+Yay, Congratulations! You've just run your first automation script with WebdriverIO. Let's step it up a notch and create a real test.
+
+## Let's get serious
+
+*(If you haven't already, navigate back to the project root directory)*
+
+This was just a warm up. Let's move forward and run WebdriverIO with the test runner. If you want to use WebdriverIO in your project for integration testing we recommend to use the test runner because it comes with a lot of useful features that makes your life easier. The first step is to create a config file. To do that just run the configuration utility:
+
+```sh
+$ ./node_modules/.bin/wdio config
+```
+
+A question interface pops up. It will help to create the config easy and fast. If you are not sure what to answer follow this answers:
+
+__Q: Where do you want to execute your tests?__<br>
+A: _On my local machine_<br>
+<br>
+__Q: Which framework do you want to use?__<br>
+A: _mocha_<br>
+<br>
+__Q: Shall I install the framework adapter for you?__<br>
+A: _Yes_ (just press enter)<br>
+<br>
+__Q: Where are your test specs located?__<br>
+A: _./test/specs/**/*.js_ (just press enter)<br>
+<br>
+__Q: Which reporter do you want to use?__<br>
+A: _dot_ (just press space and enter)<br>
+<br>
+__Q: Shall I install the reporter library for you?__<br>
+A: _Yes_ (just press enter)<br>
+<br>
+__Q: Do you want to add a service to your test setup?__<br>
+A: none (just press enter, let's skip this for simplicity)<br>
+<br>
+__Q: Level of logging verbosity:__<br>
+A: _silent_ (just press enter)<br>
+<br>
+__Q: In which directory should screenshots gets saved if a command fails?__<br>
+A: _./errorShots/_ (just press enter)<br>
+<br>
+__Q: What is the base url?__<br>
+A: _http://localhost_ (just press enter)<br>
+
+That's it! The configurator now installs all required packages for you and creates a config file with the name `wdio.conf.js`. Next step is to create your first spec file (test file). For that create a test folder like this:
+
+```sh
+$ mkdir -p ./test/specs
+```
+
+Now let's create a simple spec file in that new folder:
+
+```js
+var assert = require('assert');
+
+describe('webdriver.io page', function() {
+    it('should have the right title - the fancy generator way', function () {
+        browser.url('http://webdriver.io');
+        var title = browser.getTitle();
+        assert.equal(title, 'WebdriverIO - WebDriver bindings for Node.js');
+    });
+});
+```
+
+The last step is to execute the test runner. To do so just run:
+
+```sh
+$ ./node_modules/.bin/wdio wdio.conf.js
+```
+
+Hurray! The test should pass and you can start writing integration tests with WebdriverIO. If you are interested in more in depth video on-boarding tutorials, feel free to check out our very own course called [learn.webdriver.io](http://learn.webdriver.io/). Also our community has collected a lot of [boilerplate projects](/guide/getstarted/boilerplate.html) that can help you to get started.

static/js/ketcher2/node_modules/webdriverio/docs/guide/getstarted/boilerplate.md

@@ -0,0 +1,78 @@
+name: boilerplate
+category: getstarted
+tags: guide
+index: 2
+title: WebdriverIO - Boilerplate Projects
+---
+
+# Boilerplate Projects
+
+Over the time our community has developed a bunch of boilerplate projects that can be used as inspiration to set up the own test suite.
+
+## [webdriverio/cucumber-boilerplate](https://github.com/webdriverio/cucumber-boilerplate)
+
+Our very own boilerplate for Cucumber test suites. We created over 150 predefined step definitions for you so that you can start write feature files for your project right away.
+
+- Framework: Cucumber
+- Features:
+    - over 150 predefined steps that cover almost everything you need
+    - integration of WebdriverIO's Multiremote functionality
+    - own demo app
+
+## [saucelabs-sample-test-frameworks/JS-Mocha-WebdriverIO-Selenium](https://github.com/saucelabs-sample-test-frameworks/JS-Mocha-WebdriverIO-Selenium)
+
+Simple boilerplate project that runs multiple browser on [SauceLabs](https://saucelabs.com/) in parallel.
+
+- Framework: Mocha
+- Features:
+    - Page Object usage
+    - Integration with [SauceLabs](https://saucelabs.com/)
+
+## [jonyet/webdriverio-boilerplate](https://github.com/jonyet/webdriverio-boilerplate)
+
+Designed to be quick to get you started without getting terribly complex, as well as to share examples of how one can leverage external node modules to work in conjunction with wdio specs.
+
+- Framework: Mocha
+- Features:
+    - examples for using Visual Regression testing with WebdriverIO v4
+    - cloud integration with [BrowserStack](https://www.browserstack.com/)
+    - Page Objects usage
+
+## [cognitom/webdriverio-examples](https://github.com/cognitom/webdriverio-examples)
+
+Project with various examples to setup WebdriverIO with an internal grid and PhantomJS or using cloud services like [TestingBot](https://testingbot.com/).
+
+- Framework: Mocha
+- Features:
+    - examples for the tunneling feature from TestingBot
+    - standalone examples
+    - simple demonstration of how to integrate PhantomJS as a service so no that no Java is required
+
+## [michaelguild13/Selenium-WebdriverIO-Mocha-Chai-Sinon-Boilerplate](https://github.com/michaelguild13/Selenium-WebdriverIO-Mocha-Chai-Sinon-Boilerplate)
+
+Enhance testing stack demonstration with Mocha and Chai allows you to write simple assertion using the [Chai](http://chaijs.com/) assertion library.
+
+- Framework: Mocha
+- Features:
+    - Chai integration
+    - Babel setup
+
+## [dcypherthis/wdio-boilerplate-cucumber](https://github.com/dcypherthis/wdio-boilerplate-cucumber)
+
+This project is an example of how to get started with WebdriverIO for Selenium testing in Node.js. It makes use of the Cucumber BDD framework and works with dot, junit, and allure reporters. It is ES6 friendly (via babel-register) and uses Grunt to manage tasks.
+
+- Framework: Cucumber
+- Features:
+    - detailed documentation
+    - runs tests in a [Docker](https://www.docker.com/) container
+    - Babel setup
+
+## [WillLuce/WebdriverIO_Typescript](https://github.com/WillLuce/WebdriverIO_Typescript)
+
+This directory contains the WebdriverIO page object example written using TypeScript.
+
+- Framework: Mocha
+- Features:
+    - examples of Page Object Model implemenetation
+    - Intellisence
+

static/js/ketcher2/node_modules/webdriverio/docs/guide/getstarted/configuration.md

@@ -0,0 +1,274 @@
+name: configuration
+category: getstarted
+tags: guide
+index: 1
+title: WebdriverIO - Configuration
+---
+
+# Configuration
+
+If you create a WebdriverIO instance, you need to define some options in order to set the proper
+capabilities and settings. When calling the `remote` method like:
+
+```js
+var webdriverio = require('webdriverio');
+var client = webdriverio.remote(options);
+```
+
+you need to pass in an options object to define your Webdriver instance. Note that this is only necessary if you run WebdriverIO as a standalone package. If you are using the wdio test runner, these options belong in your `wdio.conf.js` configuration file. The following options can be defined:
+
+### desiredCapabilities
+Defines the capabilities you want to run in your Selenium session. See the [Selenium documentation](https://github.com/SeleniumHQ/selenium/wiki/DesiredCapabilities)
+for a list of the available `capabilities`. Also useful is Sauce Labs [Automated Test Configurator](https://wiki.saucelabs.com/display/DOCS/Platform+Configurator#/)
+that helps you to create this object by clicking together your desired capabilities.
+
+Refer to the [cloud service docs](/guide/usage/cloudservices.html) for further
+service specific options.
+
+Type: `Object`<br>
+Default: `{ browserName: 'firefox' }`<br>
+
+**Example:**
+
+```js
+browserName: 'chrome',    // options: `firefox`, `chrome`, `opera`, `safari`
+version: '27.0',          // browser version
+platform: 'XP',           // OS platform
+tags: ['tag1','tag2'],    // specify some tags (e.g. if you use Sauce Labs)
+name: 'my test'           // set name for test (e.g. if you use Sauce Labs)
+pageLoadStrategy: 'eager' // strategy for page load
+```
+
+**Details:**
+
+`pageLoadStrategy` is implemented in Selenium [2.46.0](https://github.com/SeleniumHQ/selenium/blob/master/java/CHANGELOG#L494), and apparently, it is only working on Firefox. The valid values are:
+
+ `normal` - waits for `document.readyState` to be 'complete'. This value is used by default.<br>
+ `eager`  - will abort the wait when `document.readyState` is 'interactive' instead of waiting for 'complete'.<br>
+ `none`   - will abort the wait immediately, without waiting for any of the page to load.
+
+### logLevel
+Level of logging verbosity.
+
+__verbose:__ everything gets logged<br>
+__silent:__ nothing gets logged<br>
+__command:__ url to Selenium server gets logged (e.g. `[15:28:00]  COMMAND     GET      "/wd/hub/session/dddef9eb-82a9-4f6c-ab5e-e5934aecc32a/title"`)<br>
+__data:__ payload of the request gets logged (e.g. `[15:28:00]  DATA                {}`)<br>
+__result:__ result from the Selenium server gets logged (e.g. `[15:28:00]  RESULT              "Google"`)
+
+Type: `String`<br>
+Default: *silent*<br>
+Options: *verbose* | *silent* | *command* | *data* | *result*
+
+### logOutput
+Pipe WebdriverIO logs into a file. You can either define a directory, and WebdriverIO generates a filename for the log file
+or you can pass in a writeable stream, and everything gets redirected to that (last one doesn't work yet with the wdio runner).
+
+Type: `String|writeable stream`<br>
+Default: *null*
+
+### protocol
+Protocol to use when communicating with the Selenium standalone server (or driver).
+
+Type: `String`<br>
+Default: *http*
+
+### host
+Host of your WebDriver server.
+
+Type: `String`<br>
+Default: *127.0.0.1*
+
+### port
+Port your WebDriver server is on.
+
+Type: `Number`<br>
+Default: *4444*
+
+### path
+Path to WebDriver server.
+
+Type: `String`<br>
+Default: */wd/hub*
+
+### baseUrl
+Shorten `url` command calls by setting a base url. If your `url` parameter starts with `/`, the base url gets prepended.
+
+Type: `String`<br>
+Default: *null*
+
+### connectionRetryTimeout
+Timeout for any request to the Selenium server
+
+Type: `Number`<br>
+Default: *90000*
+
+### connectionRetryCount
+Count of request retries to the Selenium server
+
+Type: `Number`<br>
+Default: *3*
+
+### coloredLogs
+Enables colors for log output
+
+Type: `Boolean`<br>
+Default: *true*
+
+### bail
+If you only want to run your tests until a specific amount of tests have failed use bail (default is 0 - don't bail, run all tests).
+
+Type: `Number`<br>
+Default: *0* (don't bail, run all tests)
+
+### screenshotPath
+Saves a screenshot to a given path if the Selenium driver crashes
+
+Type: `String`|`null`<br>
+Default: *null*
+
+### screenshotOnReject
+Attaches a screenshot of a current page to the error if the Selenium driver crashes.
+Can be specified as object to set the timeout and count of retries on the attempt to take screenshot.
+
+Type: `Boolean`|`Object`<br>
+Default: *false*
+
+**Note**: Attaching screenshot to the error uses extra time to get screenshot and extra memory to store it. So for the sake of performance it is disabled by default.
+
+**Example:**
+
+```js
+// take screenshot on reject
+screenshotOnReject: true
+
+// take screenshot on reject and set some options
+screenshotOnReject: {
+    connectionRetryTimeout: 30000,
+    connectionRetryCount: 0
+}
+```
+
+### waitforTimeout
+Default timeout for all waitForXXX commands. Note the lowercase `f`.
+
+Type: `Number`<br>
+Default: *1000*
+
+### waitforInterval
+Default interval for all waitForXXX commands.
+
+Type: `Number`<br>
+Default: *500*
+
+### queryParams
+A key-value store of query parameters to be added to every selenium request.
+Type: `Object`<br>
+Default: None
+
+**Example:**
+
+```js
+queryParams: {
+  specialKey: 'd2ViZHJpdmVyaW8='
+}
+
+// Selenium request would look like:
+// http://127.0.0.1:4444/v1/session/a4ef025c69524902b77af5339017fd44/window/current/size?specialKey=d2ViZHJpdmVyaW8%3D
+```
+
+## debug
+
+Enables node debugging
+
+Type: `Boolean`<br>
+Default: *false*
+
+## execArgv
+Node arguments to specify when launching child processes
+
+Type: `Array of String`<br>
+Default: *null*
+
+## Setup [Babel](https://babeljs.io/) to write tests using next generation JavaScript
+
+**Note: these instructions are for Babel 6.  Using Babel 5 is not recommended.**
+
+First, install babel dependencies:
+```
+npm install --save-dev babel-register babel-preset-es2015
+```
+
+There are multiple ways to setup Babel using the wdio testrunner. If you are running Cucumber or Jasmine tests, you just need
+to register Babel in the before hook of your config file
+
+```js
+    before: function() {
+        require('babel-register');
+    },
+```
+
+If you run Mocha tests, you can use Mocha's internal compiler to register Babel, e.g.:
+
+```js
+    mochaOpts: {
+        ui: 'bdd',
+        compilers: ['js:babel-register'],
+        require: ['./test/helpers/common.js']
+    },
+```
+
+### `.babelrc` settings
+
+Using `babel-polyfill` is not recommended with `webdriverio`; if you need such features, use [`babel-runtime`](https://babeljs.io/docs/plugins/transform-runtime/) instead by running
+```
+npm install --save-dev babel-plugin-transform-runtime babel-runtime
+```
+and including the following in your `.babelrc`:
+```json
+{
+  "presets": ["es2015"],
+  "plugins": [
+    ["transform-runtime", {
+      "polyfill": false
+    }]
+  ]
+}
+```
+
+Instead of `babel-preset-es2015`, you may use `babel-preset-es2015-nodeX`, where `X` is your Node major version, to avoid unnecessary polyfills like generators:
+```
+npm install --save-dev babel-preset-es2015-node6
+```
+```json
+{
+  "presets": ["es2015-node6"],
+  "plugins": [
+    ["transform-runtime", {
+      "polyfill": false,
+      "regenerator": false
+    }]
+  ]
+}
+```
+
+## Setup [TypeScript](http://www.typescriptlang.org/)
+
+Similar to Babel setup, you can register TypeScript to compile your .ts files in your before hook of your config file.
+You will need [ts-node](https://github.com/TypeStrong/ts-node) as an installed devDependency.
+
+```js
+    before(function() {
+        require('ts-node/register');
+    }),
+```
+
+Similarly for mocha:
+
+```js
+    mochaOpts: {
+        ui: 'bdd',
+        compilers: ['ts:ts-node/register'],
+        requires: ['./test/helpers/common.js']
+    },
+```

static/js/ketcher2/node_modules/webdriverio/docs/guide/getstarted/install.md

@@ -0,0 +1,55 @@
+name: install
+category: getstarted
+tags: guide
+index: 0
+title: WebdriverIO - Install
+---
+
+# Install
+
+You will need to have [Node.js](http://nodejs.org/) and [NPM](https://www.npmjs.org/) installed on your machine. Check out their project websites for more instructions. If you want to have WebdriverIO integrated into your test suite, then install it locally with:
+
+```sh
+$ npm install webdriverio --save-dev
+```
+
+The test runner is called `wdio` and should be available after the install was successful:
+
+```sh
+$ ./node_modules/.bin/wdio --help
+```
+
+You can also install the package globally on your machine and use the `wdio` directly from the command line. However it is recommended to install it per project.
+
+## Set up your Selenium environment
+
+There are two ways of setting up your Selenium environment: as a standalone package or by installing the
+server and browser driver separately.
+
+### Use of existing standalone package
+
+The simplest way to get started is to use one of the NPM selenium standalone
+packages like: [vvo/selenium-standalone](https://github.com/vvo/selenium-standalone). After installing
+it (globally) you can run your server by executing:
+
+```sh
+$  selenium-standalone start
+```
+
+If you are using the wdio testrunner you might be interested in the [Selenium Standalone Service](/guide/services/selenium-standalone.html) that starts the server for you everytime before the test starts.
+
+You can also run the selenium server separately from your test setup. To do so you need to get the newest version of the selenium standalone server [here](http://docs.seleniumhq.org/download/). Just download the jar file somewhere on your system. After that start your terminal and execute the file via
+
+```sh
+$ java -jar /your/download/directory/selenium-server-standalone-3.0.1.jar
+```
+
+With the latest version of Selenium most of the drivers for the browser come with an external driver that has to be downloaded and setup.
+
+## Setup Chrome
+
+The [Chromedriver](https://sites.google.com/a/chromium.org/chromedriver/home) is a standalone server which implements WebDriver's wire protocol for Chromium. It is being developed by members of the Chromium and WebDriver team. For running Chrome browser tests on your local machine you need to download ChromeDriver from the project website and make it available on your machine by setting the `PATH` to the ChromeDriver executable.
+
+## Setup Firefox
+
+The same applies for Firefox. It is driven by the GeckoDriver that translates calls into the [Marionette](https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette) automation protocol. To run tests on Firefox with Selenium standalone server v3 or newer you also need to download the latest driver [here](https://github.com/mozilla/geckodriver/releases) and make it available in the `PATH` of your machine.

static/js/ketcher2/node_modules/webdriverio/docs/guide/getstarted/modes.md

@@ -0,0 +1,53 @@
+name: modes
+category: getstarted
+tags: guide
+index: 3
+title: WebdriverIO - How to use WebdriverIO
+---
+
+# How to use WebdriverIO
+
+WebdriverIO can be used for various purposes. It implements the Webdriver protocol API and can run browser in an automated way. The framework is designed to work in any arbitrary environment and for any kind of task. It is independent from any 3rd party frameworks and only requires Node.js to run.
+
+### Standalone Mode
+
+The probably simplest form to run WebdriverIO is in standalone mode. This has nothing to do with the Selenium server file which is usually called `selenium-server-standalone`. It basically just means that you require the `webdriverio` package in your project and use the API behind it to run your automation. Here is a simple example:
+
+```js
+var webdriverio = require('webdriverio');
+var options = { desiredCapabilities: { browserName: 'chrome' } };
+var client = webdriverio.remote(options);
+
+client
+    .init()
+    .url('https://duckduckgo.com/')
+    .setValue('#search_form_input_homepage', 'WebdriverIO')
+    .click('#search_button_homepage')
+    .getTitle().then(function(title) {
+        console.log('Title is: ' + title);
+        // outputs: "Title is: WebdriverIO (Software) at DuckDuckGo"
+    })
+    .end();
+```
+
+Using WebdriverIO in standalone mode allows you to integrate this automation tool in your own (test) project to create a new automation library. Popular examples of that are [Chimp](https://chimp.readme.io/) or [CodeceptJS](http://codecept.io/). You can also write plain Node scripts to scrape the World Wide Web for content or anything else where a running browser is required.
+
+### The WDIO Testrunner
+
+The main purpose of WebdriverIO though is end to end testing on big scale. We therefore implemented a test runner that helps you to build a reliable test suite that is easy to read and maintain. The test runner takes care of many problems you are usually facing when working with plain automation libraries. For one it organizes your test runs and splits up test specs so your tests can be executed with maximum concurrency. It also handles session management and provides a lot of features that help you to debug problems and find errors in your tests. Here is an same example from above written as test spec and executed by wdio:
+
+```js
+describe('DuckDuckGo search', function() {
+    it('searches for WebdriverIO', function() {
+        browser.url('https://duckduckgo.com/');
+        browser.setValue('#search_form_input_homepage', 'WebdriverIO');
+        browser.click('#search_button_homepage');
+
+        var title = browser.getTitle();
+        console.log('Title is: ' + title);
+        // outputs: "Title is: WebdriverIO (Software) at DuckDuckGo"
+    });
+});
+```
+
+The test runner is an abstraction of popular test frameworks like Mocha, Jasmine or Cucumber. Different than using the standalone mode all commands that get executed by the wdio test runner are synchronous. That means that you don't use promises anymore to handle async code. To run your tests using the wdio test runner check out the [Getting Started](/guide/testrunner/gettingstarted.html) section for more information.

static/js/ketcher2/node_modules/webdriverio/docs/guide/getstarted/upgrade.md

@@ -0,0 +1,43 @@
+name: upgrade
+category: getstarted
+tags: guide
+index: 5
+title: WebdriverIO - How to upgrade from v3 to v4
+---
+
+How to upgrade from v3 to v4
+============================
+
+If you have already written tons of tests using v3 but you want to upgrade to v4 then you have two opportunities:
+
+1. You can simply update to v4 and continue to run your tests asynchronous. To do so make sure to set the `sync` property in your `wdio.conf.js` to `false`. Note that in v4 wdio splits up the test specs and starts one session per capability per spec file. If you run your tests in the cloud make sure to limit this behavior (using [`maxInstances`](https://github.com/webdriverio/webdriverio/blob/master/examples/wdio.conf.js#L52-L60)) before you exceed the concurrency limit.
+2. If you want to transform your test specs from asynchronous behavior using promises to synchronous but don't have time to rewrite your whole suite, you can run some specs asynchronous and some synchronous. First of all you need to set all spec function to run asynchronous. You can do that by giving each test block (e.g. `it` in Mochas BDD testing) or step definition the function name `async`:
+
+```js
+describe('some feature', function () {
+    // ...
+    it('I am an old test running asynchronous', function async () {
+        return browser
+            .url('...')
+            .click('button=some button')
+            .getText('.myElem').then(function (text) {
+                expect(text).to.be.equal('some text');
+            })
+    });
+
+    it('I am a new test running synchronous', function () {
+        browser.url('...');
+
+        var button = browser.element('.myButton');
+        button.click();
+
+        expect(browser.getText('label')).to.be.equal('some text');
+    });
+});
+```
+
+This way old and new tests can coexist and you can move your old test time after time to the new synchronous way of writing specs.
+
+Also make sure to add the desired framework adapters to your dependencies. In v4 all frameworks as well as reporters live as own adapter packages on NPM and need to be additionally installed. Besides the spec reporter (will be published later too) we were able to port all frameworks and reporter into own packages.
+
+Nevertheless an upgrade from v3 to v4 can lead to break your build even though you've configured everything properly. We can not guarantee that one of the steps above work for you. The worst case is that you have to stick to v3 or rewrite everything.

static/js/ketcher2/node_modules/webdriverio/docs/guide/getstarted/v4.md

@@ -0,0 +1,55 @@
+name: v4
+category: getstarted
+tags: guide
+index: 4
+title: WebdriverIO - What's new in WebdriverIO?
+---
+
+# What's new in WebdriverIO v4?
+
+History has proven to us: no major version change without rewriting the whole code base. This time we have rewritten everything into ES2016 conforming JavaScript and we use Babel now to compile the code before pushing it to NPM. This allows us not only to specify a project wide code style using `ESLint`, it also sets an important milestone for the future development of WebdriverIO. One of the next big changes compared to v3 is that we split up the codebase into multiple packages. That means that all reporters and framework adaptations  have to be installed separately. Note: if you have installed WebdriverIO globally you also need to install these extra packages globally. The schema of the new package system is as follows:
+
+#### Framework Adaptations
+- example plugins: [wdio-mocha-framework](https://github.com/webdriverio/wdio-mocha-framework), [wdio-jasmine-framework](https://github.com/webdriverio/wdio-jasmine-framework), [wdio-cucumber-framework](https://github.com/webdriverio/wdio-cucumber-framework)
+- use naming convention is `wdio-*-framework`
+- use NPM keywords wdio-plugin, wdio-framework
+
+#### Reporters
+- example plugins: [wdio-dot-reporter](https://github.com/webdriverio/wdio-dot-reporter), [wdio-junit-reporter](https://github.com/webdriverio/wdio-junit-reporter), [wdio-allure-reporter](https://github.com/webdriverio/wdio-allure-reporter)
+- use naming convention is `wdio-*-reporter`
+- use NPM keywords wdio-plugin, wdio-reporter
+
+#### Services
+- example services: [wdio-sauce-service](https://github.com/webdriverio/wdio-sauce-service)
+- use naming convention is `wdio-*-service`
+- use NPM keywords wdio-plugin, wdio-service
+
+We really appreciate every new plugin that gets developed and may help other people to run better tests. If you have created such a plugin make sure to create a pull request to our [configuration utility](https://github.com/webdriverio/webdriverio/blob/master/lib/cli.js#L13-L33) so your package will be suggested if someone runs the wdio configurator.
+
+### It's all synchronous
+
+One of the probably biggest changes is the way WebdriverIO handles async in the wdio testrunner now. Many developers that moved away from Java to run their e2e tests in Node.js struggled with async handling of commands in their test suites. Also beginners had to learn the concept of promises to properly build up reliable tests. This is now over. All commands now block the execution of the test process until they've resolved. No `then` calls have to be done anymore, we can just assign the direct response of the Selenium server to a variable, like:
+
+```js
+describe('webdriver.io page', function() {
+    it('should have the right title', function () {
+        browser.url('/');
+        var title = browser.getTitle();
+        assert.equal(title, 'WebdriverIO - WebDriver bindings for Node.js');
+    });
+});
+```
+
+WebdriverIO uses the popular [Fibers](https://www.npmjs.com/package/fibers) package which is a Node.js plugin and compatible with all operating systems and various Node.js versions. It is also used by other big projects like [Meteor](https://www.meteor.com/) and is pretty stable and in active development. If you have used generators in v3 you can easily upgrade to v4 by removing the asterisks in your spec definitions as well as all `yield` words in your tests (there is no support for generators in v4 anymore).
+
+### New concept of services
+
+One really exciting new feature is the concept of services. These are little add-ons that help you to simplify tests, manage your test suite and integrate results with all kinds of 3rd party integrations. As a showcase service we created the package `wdio-sauce-service` which is a service for running tests on Sauce Labs. Of course, you can run tests using Sauce without that service but using the package reduces overhead and makes the setup way easier. For example, it updates the job status automatically and comes with a [Sauce Connect](https://wiki.saucelabs.com/display/DOCS/Sauce+Connect) integration to securely run your local tests in the cloud. We hope that the community is building a lot more services and 3rd party integrations.
+
+### Reliable test execution through retry mechanisms
+
+It's a known issue that e2e tests are fragile and not always reliable. It's the job of WebdriverIO to tackle this problem and prevent flakes from happening. An annoying and common error is the so called stale element reference error in Selenium where the element you are requesting got re-rendered causing the driver to lose its connection to it. These errors used to happen in random locations in your tests suite and there was almost no way to prevent them. In v4 we have now implemented a retry mechanism that checks for that error and automatically reruns the command for you. This mechanism can also be used to prevent other common problems from happening and will be improved with the next couple of versions. It also appears that some users faced connection issues in their internal grid system. This is now also handled by WebdriverIO which as of v4 will automatically retry all failing requests to the Selenium server.
+
+### Hook me up!
+
+Hooks are an important instrument to get information about the running test process. In the new version we introduced a lot of new hooks that allow you to interfere with the test at any time. You can make async requests to 3rd party tools as well as log certain states to get a better overview about the system you are testing. These are all of the new hooks that were implemented: `beforeSession`, `beforeSuite`, `beforeHook`, `beforeTest`, `beforeCommand`, `afterCommand`, `afterTest`, `afterHook`, `afterSuite`, `afterSession`, `onError` and for Cucumber tests: `beforeFeature`, `beforeScenario`, `beforeStep`, `afterFeature`, `afterScenario`, `afterStep`. Each of these hooks will wait to continue with the test process until synchronous WebdriverIO commands have finished or the returning promise has been resolved.

static/js/ketcher2/node_modules/webdriverio/docs/guide/plugins/browserevent.md

@@ -0,0 +1,61 @@
+name: browserevent
+# category: plugins
+tags: guide
+title: WebdriverIO - Browserevent
+---
+
+Browserevent
+============
+
+This is an experimental feature that helps you to listen on events within the browser. It
+is currently **only** supported in Chrome browser (other browser will eventually follow).
+To register an event call the `addEventListener` command. If an event gets invoked it returns
+almost the complete event object that got caught within the browser. Only the `Window` attribute
+will be removed to avoid circular references. All objects from type `HTMLElement` will be
+replaced by their xPath. This will help you to query and identify this element with WebdriverIO.
+
+## Install
+
+First install this plugin via NPM by executing
+
+```sh
+$ npm install browserevent
+```
+
+Then just require the module and enhance your client object.
+
+```js
+var client = require('webdriverio').remote({ desiredCapabilities: { browserName: 'chrome' } }),
+    browserevent = require('browserevent');
+
+// by passing the client object as argument the module enhances it with
+// the `addEventListener` and `removeEventListener` command
+browserevent.init(client);
+```
+
+## Usage
+
+After that you can use `addEventListener` to register events on one or multiple elements
+and `removeEventListener` to remove them.
+
+**Example**
+
+```js
+client
+    .url('http://google.com')
+    .addEventListener('dblclick','#hplogo', function(e) {
+        console.log(e.target); // -> 'id("hplogo")'
+        console.log(e.type); // -> 'dblclick'
+        console.log(e.clientX, e.clientY); // -> 239 524
+    })
+    .doubleClick('#hplogo') // triggers event
+    .end();
+```
+
+**Note:** this is still an experimental feature. Some events like `hover` will not be recorded
+by the browser. But events like `click`, `doubleClick` or custom events are working flawlessly.
+You can also use this feature in cloud environments like [Sauce Labs](https://saucelabs.com)
+when using a secured tunnel that proxies the port `5555`. But be aware of possible delays due
+to slow connections between client and cloud server. Your click listener could outlast some
+selenium requests until it gets fired. I haven't faced this problem if the standalone server
+runs on my local machine.

static/js/ketcher2/node_modules/webdriverio/docs/guide/plugins/chai-webdriverio.md

@@ -0,0 +1,71 @@
+name: chai-webdriverio
+category: plugins
+tags: guide
+index: 3
+title: Chai-WebdriverIO
+---
+# chai-webdriverio
+
+
+Provides [webdriverio](https://npmjs.org/package/webdriverio) sugar for the [Chai](http://chaijs.com/) assertion library. Allows you to create expressive integration tests:
+
+```javascript
+expect('.frequency-field').to.have.text('One time')
+expect('.toggle-pane').to.not.be.visible()
+```
+
+## What sorts of assertions can we make?
+
+All assertions start with a [WebdriverIO-compatible selector](http://webdriver.io/guide/usage/selectors.html), for example:
+
+- `expect('.list')` (CSS selector)
+- `expect('a[href=http://google.com]')` (CSS Selector)
+- `expect('//BODY/DIV[6]/DIV[1]')` (XPath selector)
+- `expect('a*=Save')` (Text selector)
+
+Then, we can add our assertion to the chain.
+
+- `expect(selector).to.be.there()` - Test whether the element exists.
+- `expect(selector).to.be.visible()` - Test whether or not the element is visible.
+- `expect(selector).to.have.text('string')` - Test the text value of the dom element against supplied string. Exact matches only.
+- `expect(selector).to.have.text(/regex/)` - Test the text value of the dom element against the supplied regular expression.
+- `expect(selector).to.have.count(number)` - Test how many elements exist in the dom with the supplied selector
+
+You can also always add a `not` in there to negate the assertion:
+
+- `expect(selector).not.to.have.text('property')`
+
+## Setup
+
+Setup is pretty easy. Just:
+
+```javascript
+var chai = require('chai');
+var chaiWebdriver = require('chai-webdriverio').default;
+chai.use(chaiWebdriver(browser));
+
+// And you're good to go!
+browser.url('http://github.com');
+chai.expect('#site-container h1.heading').to.not.contain.text("I'm a kitty!");
+```
+
+## Contributing
+
+so easy.
+
+```bash
+npm                # download the necessary development dependencies
+npm transpile      # compile ES6 into javascript
+npm test           # build and run the specs
+```
+
+**Contributors:**
+
+* [@mltsy](https://github.com/mltsy) : `exist`, `text` assertions, documentation & test adjustments
+
+## License
+
+Apache 2.0
+
+## Thanks
+Thanks to [goodeggs](https://github.com/goodeggs/) for creating: [chai-webdriver](https://github.com/goodeggs/chai-webdriver) which inspired this module.

static/js/ketcher2/node_modules/webdriverio/docs/guide/plugins/grunt-webdriver.md

@@ -0,0 +1,68 @@
+name: Grunt
+category: plugins
+tags: guide
+index: 1
+title: WebdriverIO - WDIO with Grunt
+---
+
+# WDIO with Grunt
+
+`grunt-webdriver` is a [grunt plugin](http://gruntjs.com/) to run selenium tests with the [WebdriverIO](http://webdriver.io) testrunner.
+
+## Getting Started
+
+If you haven't used [Grunt](http://gruntjs.com/) before, be sure to check out the [Getting Started](http://gruntjs.com/getting-started) guide, as it explains how to create a [Gruntfile](http://gruntjs.com/sample-gruntfile) as well as install and use Grunt plugins. Once you're familiar with that process, you may install this plugin with this command:
+
+```shell
+npm install --save-dev grunt-webdriver
+```
+
+Once the plugin has been installed, it may be enabled inside your gruntfile with this line of JavaScript:
+
+```js
+grunt.loadNpmTasks('grunt-webdriver');
+```
+
+## The "webdriver" task
+
+### Overview
+
+In your project's Gruntfile, add a section named `webdriver` to the data object passed into `grunt.initConfig()`. Your test should contain a `configFile` property with a path to your wdio config. You can pass in additional options as cli arguments.
+
+_Run this task with the `grunt webdriver` command._
+
+```js
+grunt.initConfig({
+  webdriver: {
+    test: {
+        configFile: './test/wdio.conf.js'
+    }
+  },
+  // ...
+})
+```
+
+The plugin is an easy helper to run WebdriverIO tests using the wdio test runner. You can find more information about the test runner on our [docs page](http://webdriver.io/guide/testrunner/gettingstarted.html).
+
+#### Example using [Sauce Labs](https://saucelabs.com)
+
+To use a cloud service like [Sauce Labs](https://saucelabs.com) make sure you define `user` and `key` properties like in the example below to authenticate yourself with your username and access key.
+
+```js
+grunt.initConfig({
+  webdriver: {
+    options: {
+        user: SAUCE_USERNAME,
+        key: SAUCE_ACCESS_KEY
+    },
+    test: {
+        configFile: './test/wdio.conf.js'
+    }
+  },
+  // ...
+})
+```
+
+### Options
+
+All options get passed into to the wdio testrunner. You should define your main configurations within your wdio config file. The plugin allows you to easy overwrite them. You can find all available cli arguments here: [http://webdriver.io/guide/testrunner/gettingstarted.html](http://webdriver.io/guide/testrunner/gettingstarted.html)

static/js/ketcher2/node_modules/webdriverio/docs/guide/plugins/gulp-webdriver.md

@@ -0,0 +1,41 @@
+name: Gulp
+category: plugins
+tags: guide
+index: 0
+title: WebdriverIO - gulp-webdriver
+---
+
+gulp-webdriver
+==============
+
+`gulp-webdriver` is a [gulp plugin](http://gulpjs.com/) to run selenium tests with the [WebdriverIO](http://webdriver.io) testrunner.
+
+## Install
+
+```shell
+npm install gulp-webdriver --save-dev
+```
+
+## Usage
+
+You can run WebdriverIO locally running this simple task:
+
+```js
+gulp.task('test:e2e', function() {
+    return gulp.src('wdio.conf.js').pipe(webdriver());
+});
+```
+
+gulp-webdriver makes the wdio testrunner easy accessible and allows you to run multiple config files
+sequentially. If desired you can pass additional arguments to the wdio command to specify your test.
+You can find all available options [here](http://webdriver.io/guide/testrunner/gettingstarted.html)
+or by executing `$ wdio --help` (if you have WebdriverIO installed globally).
+
+```js
+gulp.task('test:e2e', function() {
+    return gulp.src('wdio.conf.js').pipe(webdriver({
+        logLevel: 'verbose',
+        waitforTimeout: 10000
+    }));
+});
+```

static/js/ketcher2/node_modules/webdriverio/docs/guide/plugins/webdrivercss.md

@@ -0,0 +1,492 @@
+name: webdrivercss
+# category: plugins
+tags: guide
+title: WebdriverIO - WebdriverCSS
+----
+
+WebdriverCSS [![Version](http://img.shields.io/badge/version-v1.1.3-brightgreen.svg)](https://www.npmjs.org/package/webdrivercss) [![Build Status](https://travis-ci.org/webdriverio/webdrivercss.png?branch=master)](https://travis-ci.org/webdriverio/webdrivercss) [![Coverage Status](https://coveralls.io/repos/webdriverio/webdrivercss/badge.png?branch=master)](https://coveralls.io/r/webdriverio/webdrivercss?branch=master)
+============
+
+__CSS regression testing in WebdriverIO__. This plugin is an automatic visual regression-testing
+tool for [WebdriverIO](http://webdriver.io). It was inspired by [James Cryer's](https://github.com/jamescryer)
+awesome project called [PhantomCSS](https://github.com/Huddle/PhantomCSS). After
+initialization it enhances a WebdriverIO instance with an additional command called
+`webdrivercss` and enables the possibility to save screenshots of specific parts of
+your application.
+
+#### Never lose track of unwanted CSS changes:
+
+![alt text](http://webdriver.io/images/webdrivercss/hero.png "Logo Title Text 1")
+
+
+## How does it work?
+
+1. Define areas within your application that should always look the same
+2. Use WebdriverIO and WebdriverCSS to write some E2E tests and take screenshots of these areas
+3. Continue working on your application or website
+4. After a while rerun the tests
+5. If desired areas differ from previous taken screenshots an image diff gets generated and you get notified in your tests
+
+
+### Example
+
+```js
+var assert = require('assert');
+
+// init WebdriverIO
+var client = require('webdriverio').remote({desiredCapabilities:{browserName: 'chrome'}})
+// init WebdriverCSS
+require('webdrivercss').init(client);
+
+client
+    .init()
+    .url('http://example.com')
+    .webdrivercss('startpage',[
+        {
+            name: 'header',
+            elem: '#header'
+        }, {
+            name: 'hero',
+            elem: '//*[@id="hero"]/div[2]'
+        }
+    ], function(err, res) {
+        assert.ifError(err);
+        assert.ok(res.header[0].isWithinMisMatchTolerance);
+        assert.ok(res.hero[0].isWithinMisMatchTolerance);
+    })
+    .end();
+```
+
+## Install
+
+WebdriverCSS uses [GraphicsMagick](http://www.graphicsmagick.org/) for image processing. To install this
+package you'll need to have it preinstalled on your system.
+
+#### Mac OS X using [Homebrew](http://mxcl.github.io/homebrew/)
+```sh
+$ brew install graphicsmagick
+```
+
+#### Ubuntu using apt-get
+```sh
+$ sudo apt-get install graphicsmagick
+```
+
+#### Windows
+
+Download and install executables for [GraphicsMagick](http://www.graphicsmagick.org/download.html).
+Please make sure you install the right binaries desired for your system (32bit vs 64bit).
+
+After these dependencies are installed you can install WebdriverCSS via NPM as usual:
+
+```sh
+$ npm install webdrivercss
+$ npm install webdriverio # if not already installed
+```
+
+## Setup
+
+To use this plugin just call the `init` function and pass the desired WebdriverIO instance
+as parameter. Additionally you can define some options to configure the plugin. After that
+the `webdrivercss` command will be available only for this instance.
+
+* **screenshotRoot** `String` ( default: *./webdrivercss* )<br>
+  path where all screenshots get saved.
+
+* **failedComparisonsRoot** `String` ( default: *./webdrivercss/diff* )<br>
+  path where all screenshot diffs get saved.
+
+* **misMatchTolerance** `Number` ( default: *0.05* )<br>
+  number between 0 and 100 that defines the degree of mismatch to consider two images as
+  identical, increasing this value will decrease test coverage.
+
+* **screenWidth** `Numbers[]` ( default: *[]* )<br>
+  if set, all screenshots will be taken in different screen widths (e.g. for responsive design tests)
+
+* **updateBaseline** `Boolean` ( default: *false* )<br>
+  updates baseline images if comparison keeps failing.
+
+
+### Example
+
+```js
+// create a WebdriverIO instance
+var client = require('webdriverio').remote({
+    desiredCapabilities: {
+        browserName: 'phantomjs'
+    }
+}).init();
+
+// initialise WebdriverCSS for `client` instance
+require('webdrivercss').init(client, {
+    // example options
+    screenshotRoot: 'my-shots',
+    failedComparisonsRoot: 'diffs',
+    misMatchTolerance: 0.05,
+    screenWidth: [320,480,640,1024]
+});
+```
+
+## Usage
+
+WebdriverCSS enhances an WebdriverIO instance with an command called `webdrivercss`
+
+`client.webdrivercss('some_id', [{options}], callback);`
+
+It provides options that will help you to define your areas exactly and exclude parts
+that are unrelevant for design (e.g. content). Additionally it allows you to include
+the responsive design in your regression tests easily. The following options are
+available:
+
+* **name** `String` (required)<br>
+  name of the captured element
+
+* **elem** `String`<br>
+  only capture a specific DOM element, you can use all kinds of different [WebdriverIO selector strategies](http://webdriver.io/guide/usage/selectors.html) here
+
+* **width** `Number`<br>
+  define a fixed width for your screenshot
+
+* **height** `Number`<br>
+  define a fixed height for your screenshot
+
+* **x** `Number`<br>
+  take screenshot at an exact xy position (requires width/height option)
+
+* **y** `Number`<br>
+  take screenshot at an exact xy position (requires width/height option)
+
+* **exclude** `String[]|Object[]`<br>
+  exclude frequently changing parts of your screenshot, you can either pass all kinds of different [WebdriverIO selector strategies](http://webdriver.io/guide/usage/selectors.html)
+  that queries one or multiple elements or you can define x and y values which stretch a rectangle or polygon
+
+* **hide** `String[]`<br>
+  hides all elements queried by all kinds of different [WebdriverIO selector strategies](http://webdriver.io/guide/usage/selectors.html) (via `visibility: hidden`)
+
+* **remove** `String[]`<br>
+  removes all elements queried by all kinds of different [WebdriverIO selector strategies](http://webdriver.io/guide/usage/selectors.html) (via `display: none`)
+
+The following paragraphs will give you a more detailed insight how to use these options properly.
+
+### Let your test fail when screenshots differ
+
+When using this plugin you can decide how to handle design breaks. You can either just work
+with the captured screenshots or you could even break your integration test at this position. The
+following example shows how to handle design breaks within integration tests:
+
+```js
+var assert = require('assert');
+
+describe('my website should always look the same',function() {
+
+    it('header should look the same',function(done) {
+        client
+            .url('http://www.example.org')
+            .webdrivercss('header', {
+                name: 'header',
+                elem: '#header'
+            }, function(err,res) {
+                assert.ifError(err);
+
+                // this will break the test if screenshot is not within the mismatch tolerance
+                assert.ok(res.isWithinMisMatchTolerance);
+            })
+            .call(done);
+    });
+
+    // ...
+```
+
+### [Applitools Eyes](http://applitools.com) Support
+
+![Applitools Eyes](http://pravdam.biz/clientblogs/applitools2/applitools-new-logo.png)
+
+Applitools Eyes is a comprehensive automated UI validation solution with really smart image matching algorithms
+that are unique in this area. As a cloud service it makes your regression tests available everywhere and
+accessible to everyone in your team, and its automated maintenance features simplify baseline maintenance.
+
+In order to work with Applitools Eyes you need to sign up and obtain an API key. You can sign up for a
+free account [here](http://applitools.com/signup/).
+
+### Applitools Eyes Example
+
+```js
+var assert = require('assert');
+
+// create a WebdriverIO instance
+var client = require('webdriverio').remote({
+    desiredCapabilities: {
+        browserName: 'chrome'
+    }
+});
+
+// initialise WebdriverCSS for `client` instance
+require('webdrivercss').init(client, {
+    key: '<your personal API key>'
+});
+
+client
+    .init()
+    .url('http://example.com')
+    .webdrivercss('<app name>', {
+        name: '<test name>',
+        elem: '#someElement',
+        // ...
+    }, function(err, res) {
+        assert.ifError(err);
+        assert.equal(res.steps, res.strictMatches)
+    })
+    .end();
+```
+
+The following options might be interesting if you want to synchronize your taken images with
+an external API. Checkout the [webdrivercss-adminpanel](https://github.com/webdriverio/webdrivercss-adminpanel)
+for more information on that.
+
+* **api** `String`
+  URL to API interface
+* **user** `String`
+  user name (only necessary if API requires Basic Authentication or oAuth)
+* **key** `String`
+  assigned user key (only necessary if API requires Basic Authentication or oAuth)
+
+
+### Define specific areas
+
+The most powerful feature of WebdriverCSS is the possibility to define specific areas
+for your regression tests. When calling the command, WebdriverCSS will always take a screenshot of
+the whole website. After that it crops the image and creates a single copy for each element.
+If you want to capture multiple images on one page make sure you pass an array of options to
+the command. The screenshot capturing process can take a while depending on the document size
+of the website. Once you interact with the page by clicking on links, open layers or navigating
+to a new site you should call the `webdrivercss` command to take a new screenshot.
+
+To query elements you want to capture you are able to choose all kinds of different [WebdriverIO selector strategies](http://webdriver.io/guide/usage/selectors.html) or you can
+specify x/y coordinates to cover a more exact area.
+
+```js
+client
+    .url('http://github.com')
+    .webdrivercss('githubform', {
+        name: 'github-signup',
+        elem: '#site-container > div.marketing-section.marketing-section-signup > div.container > form'
+    });
+```
+
+Will capture the following:
+
+![alt text](http://webdriver.io/images/webdrivercss/githubform.png "Logo Title Text 1")
+
+**Tip:** do right click on the desired element, then click on `Inspect Element`, then hover
+over the desired element in DevTools, open the context menu and click on `Copy CSS Path` to
+get the exact CSS selector
+
+The following example uses xy coordinates to capture a more exact area. You should also
+pass a screenWidth option to make sure that your xy parameters map perfect on the desired area.
+
+```js
+client
+    .url('http://github.com')
+    .webdrivercss('headerbar', {
+        name: 'headerbar',
+        x: 110,
+        y: 15,
+        width: 980,
+        height: 34,
+        screenWidth: [1200]
+    });
+```
+![alt text](http://webdriver.io/images/webdrivercss/headerbar.png "Logo Title Text 1")
+
+
+### Exclude specific areas
+
+Sometimes it is unavoidable that content gets captured and from time to time this content
+will change of course. This would break all tests. To prevent this you can
+determine areas, which will get covered in black and will not be considered anymore. Here is
+an example:
+
+```js
+client
+    .url('http://tumblr.com/themes')
+    .webdrivercss('tumblrpage', {
+        name: 'startpage',
+        exclude: ['#theme_garden > div > section.carousel > div.carousel_slides',
+                 '//*[@id="theme_garden"]/div/section[3]',
+                 '//*[@id="theme_garden"]/div/section[4]']
+        screenWidth: [1200]
+    });
+```
+![alt text](http://webdriver.io/images/webdrivercss/exclude.png "Logo Title Text 1")
+
+Instead of using a selector strategy you can also exclude areas by specifying xy values
+which form a rectangle.
+
+```js
+client
+    .url('http://tumblr.com/themes')
+    .webdrivercss('tumblrpage', {
+        name: 'startpage',
+        exclude: [{
+            x0: 100, y0: 100,
+            x1: 300, y1: 200
+        }],
+        screenWidth: [1200]
+    });
+```
+
+If your exclude object has more then two xy variables, it will try to form a polygon. This may be
+helpful if you like to exclude complex figures like:
+
+```js
+client
+    .url('http://tumblr.com/themes')
+    .webdrivercss('polygon', {
+        name: 'startpage',
+        exclude: [{
+            x0: 120, y0: 725,
+            x1: 120, y1: 600,
+            x2: 290, y2: 490,
+            x3: 290, y3: 255,
+            x4: 925, y4: 255,
+            x5: 925, y5: 490,
+            x6: 1080,y6: 600,
+            x7: 1080,y7: 725
+        }],
+        screenWidth: [1200]
+    });
+```
+![alt text](http://webdriver.io/images/webdrivercss/exclude2.png "Logo Title Text 1")
+
+### Keep an eye on mobile screen resolution
+
+It is of course also important to check your design in multiple screen resolutions. By
+using the `screenWidth` option WebdriverCSS automatically resizes the browser for you.
+By adding the screen width to the file name WebdriverCSS makes sure that only shots
+with same width will be compared.
+
+```js
+client
+    .url('http://stephencaver.com/')
+    .webdrivercss('startpage', {
+        name: 'header',
+        elem: '#masthead',
+        screenWidth: [320,640,960]
+    });
+```
+
+This will capture the following image at once:
+
+![alt text](http://webdriver.io/images/webdrivercss/header.new.960px.png "Logo Title Text 1")
+
+**file name:** header.960px.png
+
+![alt text](http://webdriver.io/images/webdrivercss/header.new.640px.png "Logo Title Text 1")
+
+**file name:** header.640px.png
+
+![alt text](http://webdriver.io/images/webdrivercss/header.new.320px.png "Logo Title Text 1")
+
+**file name:** header.320px.png
+
+Note that if you have multiple tests running one after the other, it is important to change the first
+argument passed to the `webdrivercss()` command to be unique, as WebdriverCSS saves time by remembering
+the name of previously captured screenshots.
+
+```js
+// Example using Mocha
+it('should check the first page',function(done) {
+  client
+    .init()
+    .url('https://example.com')
+    // Make this name unique.
+    .webdrivercss('page1', [
+      {
+        name: 'test',
+        screenWidth: [320,480,640,1024]
+      }, {
+        name: 'test_two',
+        screenWidth: [444,666]
+      }
+    ])
+    .end()
+    .call(done);
+});
+
+it('should check the second page',function(done) {
+  client
+    // ...
+    // Make this name unique.
+    .webdrivercss('page2', [
+      // ..
+    ])
+    // ...
+);
+
+```
+
+
+
+### Synchronize your taken Images
+
+If you want to have your image repository available regardless where you run your tests, you can
+use an external API to store your shots. Therefor WebdriverCSS adds a `sync` function that downloads
+the repository as tarball and unzips it. After running your tests you can call this function again
+to zip the current state of your repository and upload it. Here is how this can look like:
+
+```js
+// create a WebdriverIO instance
+var client = require('webdriverio').remote({
+    desiredCapabilities: {
+        browserName: 'phantomjs'
+    }
+});
+
+// initialise WebdriverCSS for `client` instance
+require('webdrivercss').init(client, {
+    screenshotRoot: 'myRegressionTests',
+
+    // Provide the API route
+    api: 'http://example.com/api/webdrivercss'
+});
+
+client
+    .init()
+    .sync() // downloads last uploaded tarball from http://example.com/api/webdrivercss/myRegressionTests.tar.gz
+    .url('http://example.com')
+
+    // do your regression tests
+    // ...
+
+    .sync() // zips your screenshot root and uploads it to http://example.com/api/webdrivercss via POST method
+    .end();
+```
+
+This allows you to run your regression tests with the same taken shots again and again, no matter where
+your tests are executed. It also makes distributed testing possible. Regressions tests can be done not only
+by you but everyone else who has access to the API.
+
+#### API Requirements
+
+To implement such API you have to provide two routes for synchronization:
+
+* [GET] /some/route/:file
+  Should response the uploaded tarball (for example: /some/root/myProject.tar.gz)
+  Content-Type: `application/octet-stream`
+* [POST] /some/route
+  Request contains zipped tarball that needs to be stored on the filesystem
+
+If you don't want to implement this by yourself, there is already such an application prepared, checkout
+the [webdriverio/webdrivercss-adminpanel](https://github.com/webdriverio/webdrivercss-adminpanel) project.
+It provides even a web interface for before/after comparison and stuff like this.
+
+## Contributing
+Please fork, add specs, and send pull requests! In lieu of a formal styleguide, take care to
+maintain the existing coding style.
+
+Default driver instance used for testing is [PhantomJS](https://github.com/ariya/phantomjs), so you need to either have
+it installed, or change it to your preferred driver (e.g., Firefox) in the `desiredCapabilities` in the `bootstrap.js`
+file under the `test` folder.
+
+You also need a web server to serve the "site" files and have the root folder set to "webdrivercss". We use the
+[http-server package](https://www.npmjs.org/package/http-server).

static/js/ketcher2/node_modules/webdriverio/docs/guide/plugins/webdriverjs-angular.md

@@ -0,0 +1,86 @@
+name: webdriverjs-angular
+# category: plugins
+tags: guide
+title: WebdriverIO - webdriverjs-angular
+---
+
+# webdriverjs-angular [![Build Status](https://travis-ci.org/webdriverio/webdriverjs-angular.png?branch=master)](https://travis-ci.org/webdriverio/webdriverjs-angular)
+
+Functional test you angularjs application without having to `.pause()` or `.wait()`.
+
+Based on [WebdriverIO](http://webdriver.io), you access
+the same API commands but you never have to `.pause()` between actions.
+
+## Usage
+
+```js
+var webdriverjsAngular = require('webdriverjs-angular');
+var options = {
+    desiredCapabilities: {
+        browserName: 'chrome'
+    },
+    ngRoot: 'body' // main application selector
+};
+
+webdriverjsAngular
+    .remote(options)
+    .init()
+    .url('http://www.google.com')
+    .title(function(err, res) {
+        console.log('Title was: ' + res.value);
+    })
+    .end();
+```
+
+For more options, usage and API details, see
+[WebdriverIO](http://webdriver.io).
+
+## Why another webdriverjs lib?
+
+1. webdriverjs-angular is based on an existing lib, it's extending
+[WebdriverIO](http://webdriver.io).
+
+2. webdriverjs-angular is designed to work well with angularJS applications.
+AngularJS applications have a specific behavior that needs to be taken care
+of to provide easy e2e testing.
+
+## How
+
+`webdriverjs-angular` automatically waits for angularjs to [be ready](https://github.com/angular/angular.js/blob/cf686285c22d528440e173fdb65ad1052d96df3c/src/ng/browser.js#L70).
+
+So you just have to worry about what you want to do in your tests, not when
+to do it.
+
+## Why not use [angular/protractor](https://github.com/angular/protractor)?
+
+Unlike [angular/protractor](https://github.com/angular/protractor) or
+[sebv/wd-tractor](https://github.com/sebv/wd-tractor),
+we do not enhance WebdriverIO API with angularJS-related
+command.
+
+You will not find any `elementByNgBinding`, `addMockModule`,
+`hasElementByNgRepeaterRow` or any other specific, angularJS-related methods.
+
+We think your functional tests should be as framework-agnostic as possible.
+
+If you need `elementByNgBinding`, just use regular
+[WebdriverIO](http://webdriver.io)
+commands like `.element('[ng-binding=model]')`.
+
+## Local testing
+
+See [test/spec](test/spec).
+
+```shell
+# you need multiple terminal window
+
+# start a standalone selenium server
+npm install selenium-standalone phantomjs-prebuilt -g
+start-selenium
+
+# start web server
+node test/app/scripts/web-server.js
+
+# launch tests
+BROWSER=phantomjs npm test
+```

static/js/ketcher2/node_modules/webdriverio/docs/guide/plugins/webdriverrtc.md

@@ -0,0 +1,189 @@
+name: webdriverrtc
+category: plugins
+tags: guide
+index: 2
+title: WebdriverRTC
+---
+
+WebdriverRTC
+============
+
+This project is an extension to [WebdriverIO](http://webdriver.io) and enables your client instance to grep statistical data from a running WebRTC peer connection. According to the [w3 WebRTC draft](http://www.w3.org/TR/webrtc/#dom-peerconnection-getstats) all `RTCPeerConnection` objects provide a method called [`getStats`](http://www.w3.org/TR/webrtc/#widl-RTCPeerConnection-getStats-void-MediaStreamTrack-selector-RTCStatsCallback-successCallback-RTCPeerConnectionErrorCallback-failureCallback) which returns a [`RTCStats`](http://www.w3.org/TR/webrtc/#idl-def-RTCStats) object with useful information about things like packet losts or the audio input level which can be helpful in order to test your network connection or environment (e.g. did my "Mute" button really work?).
+
+This means that you can access all statistical data from `chrome://webrtc-internals` using Selenium as part of your integration tests.
+
+![chrome-internals](http://www.christian-bromann.com/webrtc-internals.png)
+
+## Prerequisites
+
+To use WebdriverRTC you need at least WebdriverIO `>=v4`
+
+## How does it work
+
+WebdriverRTC masquerades the url command and injects a script after the page has been loaded to overwrite the standard `RTCPeerConnection` interface and get access to all created `RTCPeerConnection` objects. After you start analyzing it repeats calling the `getStats` method with a specific interval and saves all results to an internal object lying in the window scope. Then you can use WebdriverRTC commands to access these information. Currently only the Chrome browser is supported. But there's more to come.
+
+## Example
+
+First install WebdriverRTC via NPM:
+
+```sh
+$ npm install webdriverrtc
+```
+
+Then enhance your client instance using the `init` method:
+
+```js
+// init WebdriverIO
+var matrix = require('webdriverio').multiremote({
+    'browserA': {
+        desiredCapabilities: {
+            browserName: 'chrome'
+        }
+    },
+    'browserB': {
+        desiredCapabilities: {
+            browserName: 'chrome'
+        }
+    }
+});
+
+var WebdriverRTC = require('webdriverrtc');
+WebdriverRTC.init(matrix,  {
+    browser: 'browserA' // define browser that collects data
+});
+```
+
+Now start your selenium session and do everything required to establish a WebRTC connection. __Note__ that you need to run WebdriverIO in multiremote mode if you don't have something fancy that autoconnects your browser. Multiremote can be really helpful in these situations where you need to control more then one browser. After the connection was established run `startAnalyzing`, make a pause for a specific amount of time and then grab the stats for that time period.
+
+```js
+matrix
+    .init()
+    .url('https://apprtc.appspot.com/r/' + channel)
+    .click('#confirm-join-button')
+    .pause(5000)
+    .startAnalyzing()
+    .getConnectionInformation(function(err, connectionType) {
+        console.log(connectionType);
+    })
+    .pause(10000)
+    .getStats(10000, function(err, mean, median, max, min, rawdata) {
+        console.log('mean:', mean);
+        console.log('median:', median);
+        console.log('max:', max);
+        console.log('min:', min);
+        console.log('rawdata', rawdata); // contains the complete RTCStatsReport with even more information (mostly browser specific)
+    })
+    .end();
+```
+
+## Commands
+
+WebdriverRTC enhances your client with a small amount of new commands in order to use this plugin properly:
+
+### startAnalyzing(<Function>)
+
+Start with WebRTC analyzing. If you want to take stats of a specific RTCPeerConnection object you can use this function to return that object. Also necessary if your app creates an object immediatelly after the page got loaded.
+
+Example:
+
+```js
+browserA.startAnalyzing(function() {
+    return appController.call_.pcClient_.pc_;
+});
+```
+
+### getConnectionInformation(callback)
+
+Get basic information about the connection. Example:
+
+```js
+matrix.getConnectionInformation(function(connection) {
+    console.log(connection);
+    /**
+     * returns:
+     * {
+     *     "transport": "udp",
+     *     "remote": {
+     *         "candidateType": "local",
+     *         "ipAddress": "192.168.1.7",
+     *         "port": "52193"
+     *     },
+     *     "local": {
+     *         "candidateType": "local",
+     *         "ipAddress": "192.168.1.7",
+     *         "port": 55375
+     *     }
+     * }
+     */
+});
+```
+
+### getStats(duration)
+
+Returns all stats within given duration in different formats.
+
+#### duration
+You can specify a specific time frame in which you want to receive the stats. If you pass in a number you will receive stats within the last x (your number) ms. You can also be more specific and pass in an object with `from` and `to` attribues and desired timestamps as value respectively. If you pass in null, you will receive the last taken stat trace.
+
+Type: *Number|Object*<br>
+
+```js
+matrix
+    .pause(10000)
+    .getStats(10000).then(function(mean) {
+        /**
+         * this test would fail if you are too loud during the test ;-)
+         */
+        assert.ok(max.audio.outbound.inputLevel < 1000, 'You are too loud!');
+        expect(video.rtt).to.be.within(0, 15);
+    });
+```
+
+This is how an example result object does look like:
+
+```json
+{
+    "audio": {
+        "inbound": {
+            "bytesReceived": 31431,
+            "jitter": 0.5,
+            "packetsReceived": 295.83,
+            "packetsLost": 0,
+            "outputLevel": 8112.5
+        },
+        "outbound": {
+            "jitter": 0.83,
+            "rtt": 1.5,
+            "packetsLost": 0,
+            "packetsSent": 297,
+            "bytesSent": 30884.33,
+            "inputLevel": 465.33
+        }
+    },
+    "video": {
+        "captureJitterMs": 25,
+        "encodeUsagePercent": 75,
+        "frameWidthInput": 640,
+        "captureQueueDelayMsPerS": 0.83,
+        "bandwidth": {
+            "actualEncBitrate": 160375,
+            "availableReceiveBandwidth": 325032.67,
+            "targetEncBitrate": 154050.5,
+            "transmitBitrate": 160351.5,
+            "retransmitBitrate": 0,
+            "bucketDelay": 6.67,
+            "availableSendBandwidth": 154050.5
+        },
+        "frameRateSent": 16,
+        "avgEncodeMs": 8.5,
+        "bytesSent": 71676.5,
+        "frameWidthSent": 640,
+        "frameHeightInput": 480,
+        "rtt": 3.17,
+        "frameHeightSent": 480,
+        "packetsLost": 0,
+        "packetsSent": 100,
+        "frameRateInput": 14.5
+    }
+}
+```

static/js/ketcher2/node_modules/webdriverio/docs/guide/reporters/allure.md

@@ -0,0 +1,68 @@
+name: allure
+category: reporters
+tags: guide
+index: 3
+title: WebdriverIO - Allure Reporter
+---
+
+Allure Reporter
+===============
+
+The Allure Reporter creates [Allure](http://allure.qatools.ru/) test reports which is an HTML generated website with all necessary information to debug your test results and take a look on error screenshots. To use it just install it from NPM:
+
+```js
+$ npm install wdio-allure-reporter --save-dev
+```
+
+Then add `allure` to the `reporters` array in your wdio.conf.js and define the output directory of the allure reports:
+
+```js
+// wdio.conf.js
+exports.config = {
+    // ...
+    reporters: ['dot', 'allure'],
+    reporterOptions: {
+        allure: {
+            outputDir: 'allure-results'
+        }
+    },
+    // ...
+}
+```
+
+`outputDir` defaults to `./allure-results`. After a test run is complete, you will find that this directory has been populated with an `.xml` file for each spec, plus a number of `.txt` and `.png` files and other attachments.
+
+## Displaying the report
+
+The results can be consumed by any of the [reporting tools](http://wiki.qatools.ru/display/AL/Reporting) offered by Allure. For example:
+
+### Jenkins
+
+Install the [Allure Jenkins plugin](http://wiki.qatools.ru/display/AL/Allure+Jenkins+Plugin), and configure it to read from the correct directory:
+
+![Configure Allure Reporter with Jenkins](https://github.com/webdriverio/wdio-allure-reporter/raw/master/docs/images/jenkins-config.png "Configure Allure Reporter with Jenkins")
+
+Jenkins will then offer a link to the results from the build status page:
+
+![Allure Link](https://github.com/webdriverio/wdio-allure-reporter/raw/master/docs/images/jenkins-results.png "Allure Link")
+
+If you open a report at the first time you probably will notice that Jenkins won't serve the assets due to security restrictions. If that is the case go to Jenkins script console (`http://<your_jenkins_instance>/script`) and put in these security settings:
+
+```
+System.setProperty("hudson.model.DirectoryBrowserSupport.CSP", "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline';")
+System.setProperty("jenkins.model.DirectoryBrowserSupport.CSP", "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline';")
+```
+
+Apply and restart the Jenkins server. All assets should now be served correctly.
+
+### Command-line
+
+Install the [Allure command-line tool](https://www.npmjs.com/package/allure-commandline), and process the results directory:
+
+```sh
+$ allure generate [allure_output_dir] && allure report open
+```
+
+This will generate a report (by default in `./allure-report`), and open it in your browser:
+
+![Allure Website](https://github.com/webdriverio/wdio-allure-reporter/raw/master/docs/images/browser.png "Allure Website")

static/js/ketcher2/node_modules/webdriverio/docs/guide/reporters/concise.md

@@ -0,0 +1,49 @@
+name: concise
+category: reporters
+tags: guide
+index: 6
+title: WebdriverIO - Concise Reporter
+---
+
+
+WDIO Concise Reporter
+=====================
+
+A concise reporter for WebdriverIO. This project is derived from [WDIO-Json-Reporter](https://github.com/fijijavis/wdio-json-reporter).
+
+![WDIO Concise Reporter error](https://github.com/FloValence/wdio-concise-reporter/blob/master/example_error.png?raw=true)
+![WDIO Concise Reporter success](https://github.com/FloValence/wdio-concise-reporter/blob/master/example_success.png?raw=true)
+
+## Installation
+
+The easiest way is to keep `wdio-concise-reporter` as a devDependency in your `package.json`.
+
+```json
+{
+  "devDependencies": {
+    "wdio-concise-reporter": "~0.0.1"
+  }
+}
+```
+
+You can simply do it by:
+
+```bash
+npm install wdio-concise-reporter --save-dev
+```
+
+Instructions on how to install `WebdriverIO` can be found [here](http://webdriver.io/guide/getstarted/install.html).
+
+## Configuration
+
+Following code shows the default wdio test runner configuration. Just add `'concise'` as reporter
+to the array.
+
+```js
+// wdio.conf.js
+module.exports = {
+  // ...
+  reporters: ['concise'],
+  // ...
+};
+```

static/js/ketcher2/node_modules/webdriverio/docs/guide/reporters/customreporter.md

@@ -0,0 +1,73 @@
+name: customreporter
+category: reporters
+tags: guide
+index: 8
+title: WebdriverIO - Custom Reporter
+---
+
+Custom Reporter
+===============
+
+You can write your own custom reporter for the wdio test runner that fits your needs. All you need to do is to create a node module that inherits from the Eventemitter object so it can receive messages from the test. The basic construction should look like:
+
+```js
+var util = require('util'),
+    events = require('events');
+
+var CustomReporter = function(options) {
+    // you can access reporter options via
+    // `options.reporterOptions`
+    // ...
+};
+
+/**
+ * Inherit from EventEmitter
+ */
+util.inherits(CustomReporter, events.EventEmitter);
+
+/**
+ * Expose Custom Reporter
+ */
+exports = module.exports = CustomReporter;
+```
+
+The only thing to do now in order to use this reporter is to assign it to the reporter property. Therefor
+your wdio.conf.js file should look like this:
+
+```js
+var CustomReporter = require('./reporter/my.custom.reporter');
+
+exports.config = {
+    // ...
+    reporters: [CustomReporter],
+    // ...
+};
+```
+
+## Events
+
+You can register event handler for several events which get triggered during the test. All these handlers will receive payloads with useful information about the current state and progress. The structure of  these payload objects depend on the event and are unified across the frameworks (Mocha, Jasmine and Cucumber). Once you implemented your custom reporter it should work for all frameworks. The following list contains all possible events you can register an event handler on:
+
+```txt
+'start'
+'suite:start'
+'hook:start'
+'hook:end'
+'test:start'
+'test:end'
+'test:pass'
+'test:fail'
+'test:pending'
+'suite:end'
+'end'
+```
+
+The event names are pretty self explanatory. To print something on a certain event, just register an event handler using the utility functions from node's [EventEmitter](https://nodejs.org/api/events.html):
+
+```js
+this.on('test:pass', function() {
+    console.log('Hurray! A test has passed!');
+});
+```
+
+Note that you can't defer the test execution in any way. All event handler should execute synchronous routines otherwise you will run into race conditions. Make sure you check out the [example section](https://github.com/webdriverio/webdriverio/tree/master/examples/wdio) where you can find an example for a custom reporter that prints the event name for each event. If you have implemented a custom reporter that can be useful for the community, don't hesitate to make a Pull Request so we can make the reporter available for the public.

static/js/ketcher2/node_modules/webdriverio/docs/guide/reporters/dot.md

@@ -0,0 +1,24 @@
+name: dot
+category: reporters
+tags: guide
+index: 0
+title: WebdriverIO - Dot Reporter
+---
+
+Dot Reporter
+============
+
+The dot reporter is the default reporter for the WDIO test runner. It's therefor a dependency of WebdriverIO and doesn't need to get downloaded. To use the dot reporter just add `'dot'` to the `reporters` array:
+
+```js
+// wdio.conf.js
+module.exports = {
+  // ...
+  reporters: ['dot'],
+  // ...
+};
+```
+
+The dot reporter prints for each test spec a dot. If colors are enabled on your machine you will see three different colors for dots. Yellow dots mean that at least one browser has executed that spec. A green dot means all browser passed that spec and a red to means that at least one browser failed that spec.
+
+![Dot Reporter](/images/dot.png "Dot Reporter")

static/js/ketcher2/node_modules/webdriverio/docs/guide/reporters/json.md

@@ -0,0 +1,124 @@
+name: json
+category: reporters
+tags: guide
+index: 5
+title: WebdriverIO - JSON Reporter
+---
+
+WDIO JSON Reporter
+===================
+
+> A WebdriverIO plugin. Report results in json format.
+
+This project was derived from the 'wdio-junit-reporter' found [here](https://github.com/webdriverio/wdio-junit-reporter)
+
+
+## Installation
+
+The easiest way is to keep `wdio-json-reporter` as a devDependency in your `package.json`.
+
+```json
+{
+  "devDependencies": {
+    "wdio-json-reporter": "~0.0.1"
+  }
+}
+```
+
+You can simply do it by:
+
+```bash
+npm install wdio-json-reporter --save-dev
+```
+
+Instructions on how to install `WebdriverIO` can be found [here](http://webdriver.io/guide/getstarted/install.html).
+
+## Configuration
+
+Following code shows the default wdio test runner configuration. Just add `'json'` as reporter
+to the array. To get some output during the test you can run the [WDIO Dot Reporter](https://github.com/webdriverio/wdio-dot-reporter) and the WDIO JSON Reporter at the same time:
+
+```js
+// wdio.conf.js
+module.exports = {
+  // ...
+  reporters: ['dot', 'json'],
+  reporterOptions: {
+    outputDir: './'
+  },
+  // ...
+};
+```
+
+## Sample Output
+```
+{
+  "start": "2016-05-04T13:05:59.006Z",
+  "end": "2016-05-04T13:06:15.539Z",
+  "capabilities": {
+    "platform": "VISTA",
+    "browserName": "chrome"
+  },
+  "host": "127.0.0.1",
+  "port": 4444,
+  "baseUrl": "http://www.some-application.com",
+  "framework": "mocha",
+  "mochaOpts": {
+    "timeout": 10000,
+    "ui": "tdd",
+    "grep": "@Smoke"
+  },
+  "suites": [
+    {
+      "name": "sample test suite number 1",
+      "duration": 12572,
+      "start": "2016-05-04T13:06:01.701Z",
+      "end": "2016-05-04T13:06:14.273Z",
+      "tests": [
+        {
+          "name": "@Smoke-Sample test number 1",
+          "start": "2016-05-04T13:06:01.701Z",
+          "end": "2016-05-04T13:06:08.162Z",
+          "duration": 6461,
+          "state": "pass"
+        },
+        {
+          "name": "@Smoke-Sample test number 2",
+          "start": "2016-05-04T13:06:08.471Z",
+          "end": "2016-05-04T13:06:13.845Z",
+          "duration": 5374,
+          "state": "fail",
+          "error": "element (#not-a-real-element) still not visible after 5000ms",
+          "errorType": "CommandError",
+          "standardError": "CommandError: element (#not-a-real-element) still not visible after 5000ms\n    at Object.Future.wait (/node_modules/fibers/future.js:449:15)\n    at Object.waitForVisible (/node_modules/wdio-sync/build/index.js:345:27)\n    at Object.create.searchForStores.value (/PageObjects/some.page.js:15:17)\n    at Context.<anonymous> (/Tests/sample.spec.js:64:25)\n    at /node_modules/wdio-sync/build/index.js:579:24\n    - - - - -\n    at elements(\"#not-a-real-element\") - isVisible.js:49:17\n    at isVisible(\"#not-a-real-element\") - waitForVisible.js:40:22"
+        }
+      ]
+    },
+    {
+      "name": "sample test suite number 2",
+      "duration": 25987,
+      "start": "2016-05-04T13:16:01.701Z",
+      "end": "2016-05-04T13:16:24.273Z",
+      "tests": [
+        {
+          "name": "@Smoke-Sample test number 3",
+          "start": "2016-05-04T13:06:11.701Z",
+          "end": "2016-05-04T13:06:18.162Z",
+          "duration": 6461,
+          "state": "pass"
+        },
+        {
+          "name": "@Smoke-Sample test number 4",
+          "start": "2016-05-04T13:06:18.471Z",
+          "end": "2016-05-04T13:06:23.845Z",
+          "duration": 5374,
+          "state": "fail",
+          "error": "element (#not-a-real-element) still not visible after 5000ms",
+          "errorType": "CommandError",          
+          "standardError": "CommandError: element (#not-a-real-element) still not visible after 5000ms\n    at Object.Future.wait (/node_modules/fibers/future.js:449:15)\n    at Object.waitForVisible (/node_modules/wdio-sync/build/index.js:345:27)\n    at Object.create.searchForStores.value (/PageObjects/some.page.js:15:17)\n    at Context.<anonymous> (/Tests/sample.spec.js:64:25)\n    at /node_modules/wdio-sync/build/index.js:579:24\n    - - - - -\n    at elements(\"#not-a-real-element\") - isVisible.js:49:17\n    at isVisible(\"#not-a-real-element\") - waitForVisible.js:40:22"
+        }
+      ]
+    }  
+  ]
+}
+```

static/js/ketcher2/node_modules/webdriverio/docs/guide/reporters/junit.md

@@ -0,0 +1,75 @@
+name: junit
+category: reporters
+tags: guide
+index: 2
+title: WebdriverIO - JUnit Reporter
+---
+
+JUnit Reporter
+==============
+
+The JUnit reporter helps you to create sophisticated reports for your CI server. To use it just install it from NPM:
+
+```js
+$ npm install wdio-junit-reporter --save-dev
+```
+
+Then add it to the `reporters` array in your wdio.conf.js and define the directory where the xml files should get stored:
+
+```js
+// wdio.conf.js
+module.exports = {
+    // ...
+    reporters: ['spec', 'junit'],
+    reporterOptions: {
+        junit: {
+            outputDir: './'
+        }
+    },
+    // ...
+};
+```
+
+WebdriverIO will create for each instance a single report file. The XML will contain all necessary information you need to debug your test:
+
+```xml
+<!-- WDIO.xunit.safari.5_1.osx10_6.64814.xml -->
+<testsuites name="safari-osx 10_6-5_1" tests="9" failures="0" errors="0" disabled="0" time="23.385">
+  <testsuite name="webdriver.io page should have the right title" tests="3" failures="0" skipped="0" disabled="0" time="17.053" timestamp="Fri Jun 26 2015 14:19:37 GMT+0200 (CEST)" id="1" file="/Users/christianbromann/Sites/projects/webdriverio/DEV/examples/runner-specs/mocha.test.js">
+      <testcase name="the good old callback way" disabled="false" time="9.848" id="4" file="/Users/christianbromann/Sites/projects/webdriverio/DEV/examples/runner-specs/mocha.test.js" status="passed">
+          <system-out type="command"><![CDATA[
+POST http://ondemand.saucelabs.com:80/wd/hub/session/3f1c00dc831f49698a50a793ca3049d9/url - {"url":"http://webdriver.io/"}
+GET http://ondemand.saucelabs.com:80/wd/hub/session/3f1c00dc831f49698a50a793ca3049d9/title - {}
+]]></system-out>
+          <system-out type="result"><![CDATA[
+POST http://ondemand.saucelabs.com:80/wd/hub/session/3f1c00dc831f49698a50a793ca3049d9/url - {"status":0,"orgStatusMessage":"The command executed successfully."}
+GET http://ondemand.saucelabs.com:80/wd/hub/session/3f1c00dc831f49698a50a793ca3049d9/title - {"status":0,"state":null,"value":"WebdriverIO - WebDriver bindings for Node.js","sessionId":"3f1c00dc831f49698a50a793ca3049d9","hCode":1473790157,"class":"org.openqa.selenium.remote.Response"}
+]]></system-out>
+      </testcase>
+      <testcase name="the promise way" disabled="false" time="3.656" id="7" file="/Users/christianbromann/Sites/projects/webdriverio/DEV/examples/runner-specs/mocha.test.js" status="passed">
+          <system-out type="command"><![CDATA[
+POST http://ondemand.saucelabs.com:80/wd/hub/session/3f1c00dc831f49698a50a793ca3049d9/url - {"url":"http://webdriver.io/"}
+GET http://ondemand.saucelabs.com:80/wd/hub/session/3f1c00dc831f49698a50a793ca3049d9/title - {}
+]]></system-out>
+          <system-out type="result"><![CDATA[
+POST http://ondemand.saucelabs.com:80/wd/hub/session/3f1c00dc831f49698a50a793ca3049d9/url - {"status":0,"orgStatusMessage":"The command executed successfully."}
+GET http://ondemand.saucelabs.com:80/wd/hub/session/3f1c00dc831f49698a50a793ca3049d9/title - {"status":0,"state":null,"value":"WebdriverIO - WebDriver bindings for Node.js","sessionId":"3f1c00dc831f49698a50a793ca3049d9","hCode":139032836,"class":"org.openqa.selenium.remote.Response"}
+]]></system-out>
+      </testcase>
+      <testcase name="the fancy generator way" disabled="false" time="3.549" id="9" file="/Users/christianbromann/Sites/projects/webdriverio/DEV/examples/runner-specs/mocha.test.js" status="passed">
+          <system-out type="command"><![CDATA[
+POST http://ondemand.saucelabs.com:80/wd/hub/session/3f1c00dc831f49698a50a793ca3049d9/url - {"url":"http://webdriver.io/"}
+GET http://ondemand.saucelabs.com:80/wd/hub/session/3f1c00dc831f49698a50a793ca3049d9/title - {}
+DELETE http://ondemand.saucelabs.com:80/wd/hub/session/3f1c00dc831f49698a50a793ca3049d9 - {}
+]]></system-out>
+          <system-out type="result"><![CDATA[
+POST http://ondemand.saucelabs.com:80/wd/hub/session/3f1c00dc831f49698a50a793ca3049d9/url - {"status":0,"orgStatusMessage":"The command executed successfully."}
+GET http://ondemand.saucelabs.com:80/wd/hub/session/3f1c00dc831f49698a50a793ca3049d9/title - {"status":0,"state":null,"value":"WebdriverIO - WebDriver bindings for Node.js","sessionId":"3f1c00dc831f49698a50a793ca3049d9","hCode":234367668,"class":"org.openqa.selenium.remote.Response"}
+DELETE http://ondemand.saucelabs.com:80/wd/hub/session/3f1c00dc831f49698a50a793ca3049d9 - {"status":0,"sessionId":"3f1c00dc831f49698a50a793ca3049d9","value":""}
+]]></system-out>
+      </testcase>
+  </testsuite>
+</testsuites>
+```
+
+This enables an excellent integration with CI systems like Jenkins. Check out the [Jenkins Integration](/guide/testrunner/jenkins.html) section to learn more about how to integrate WebdriverIO with Jenkins.

static/js/ketcher2/node_modules/webdriverio/docs/guide/reporters/spec.md

@@ -0,0 +1,47 @@
+name: spec
+category: reporters
+tags: guide
+index: 1
+title: WebdriverIO - Spec Reporter
+---
+
+Spec Reporter
+============
+
+> A WebdriverIO plugin to report in spec style.
+
+![Spec Reporter](http://webdriver.io/images/spec.png "Spec Reporter")
+
+## Installation
+
+The easiest way is to keep `wdio-spec-reporter` as a devDependency in your `package.json`.
+
+```json
+{
+  "devDependencies": {
+    "wdio-spec-reporter": "~0.0.1"
+  }
+}
+```
+
+You can simple do it by:
+
+```bash
+npm install wdio-spec-reporter --save-dev
+```
+
+Instructions on how to install `WebdriverIO` can be found [here](http://webdriver.io/guide/getstarted/install.html).
+
+## Configuration
+
+Following code shows the default wdio test runner configuration. Just add `'spec'` as reporter
+to the array.
+
+```js
+// wdio.conf.js
+module.exports = {
+  // ...
+  reporters: ['spec'],
+  // ...
+};
+```

static/js/ketcher2/node_modules/webdriverio/docs/guide/reporters/tap.md

@@ -0,0 +1,38 @@
+name: tap
+category: reporters
+tags: guide
+index: 7
+title: WebdriverIO - TAP Reporter
+---
+
+WDIO TAP reporter
+=================
+
+WebdriverIO TAP reporter which makes it possible to output tests results 
+in [TAP 13 format](https://testanything.org/tap-version-13-specification.html)
+thus the output is compatible with 
+[any TAP reporter](https://github.com/sindresorhus/awesome-tap#reporters). 
+
+## Installation
+
+```bash
+npm install wdio-tap-reporter --save-dev
+```
+
+Instructions on how to install WebdriverIO can be found [here](http://webdriver.io/guide/getstarted/install.html).
+
+## Configuration
+
+Add the reporter to your reporter list in your [wdio.conf.js](http://webdriver.io/guide/testrunner/configurationfile.html) file:
+
+```js
+exports.config = {
+  // ...
+  reporters: ['tap'],
+  // ...
+}
+```
+
+## Links
+
+- Reference to the TAP Reporter full description [https://github.com/LKay/wdio-tap-reporter](https://github.com/LKay/wdio-tap-reporter)

static/js/ketcher2/node_modules/webdriverio/docs/guide/reporters/teamcity.md

@@ -0,0 +1,35 @@
+name: teamcity
+category: reporters
+tags: guide
+index: 4
+title: WebdriverIO - Teamcity Reporter
+---
+
+WDIO Teamcity Reporter
+======================
+
+WebdriverIO Teamcity reporter which makes it possible to display test results in real-time, makes test information available on the Tests tab of the Build Results page.
+
+## Installation
+
+```bash
+npm install wdio-teamcity-reporter --save-dev
+```
+
+Instructions on how to install WebdriverIO can be found [here](http://webdriver.io/guide/getstarted/install.html).
+
+## Configuration
+
+Add the reporter to your reporter list in your [wdio.conf.js](http://webdriver.io/guide/testrunner/configurationfile.html) file:
+
+```js
+exports.config = {
+  // ...
+  reporters: ['teamcity'],
+  // ...
+}
+```
+
+## Links
+
+- Reference to the Teamcity documentation about reporting messages: [https://confluence.jetbrains.com/display/TCD65/Build+Script+Interaction+with+TeamCity](https://confluence.jetbrains.com/display/TCD65/Build+Script+Interaction+with+TeamCity)

static/js/ketcher2/node_modules/webdriverio/docs/guide/services/appium.md

@@ -0,0 +1,61 @@
+name: Appium
+category: services
+tags: guide
+index: 3
+title: WebdriverIO - Appium Service
+---
+
+Webdriver.io service plugin for Appium
+======================================
+
+[webdriver.io](http://webdriver.io/) service plugin for [Appium](http://appium.io/).  With this service installed, you need not to run Appium manually.
+
+## Installation
+
+The easiest way is to keep `wdio-appium-service` as a devDependency in your `package.json`.
+
+```json
+{
+  "devDependencies": {
+    "wdio-appium-service": "~0.2.2"
+  }
+}
+```
+
+You can this simply by adding it with:
+
+```bash
+npm install wdio-appium-service --save-dev
+```
+
+## How to Use
+
+Please register this package as service plugin and specify command line arguments in [wdio.conf](http://webdriver.io/guide/getstarted/configuration.html).  `'appium'` is used for command.  If `command` key is provided in the configuration, it will be used.
+
+```javascript
+{
+  ... // Other config
+
+  services: ['appium'],
+
+  appium: {
+    args: {
+      address: '127.0.0.1',
+      commandTimeout: '7200',
+      sessionOverride: true,
+      debugLogSpacing: true,
+      platformVersion: '9.1',
+      platformName: 'iOS',
+      showIosLog: true,
+      deviceName: 'iPhone 6',
+      nativeInstrumentsLib: true,
+      isolateSimDevice: true,
+      app: APP_PATH
+    }
+  }
+}
+```
+
+For `args`, you can specify keys in lowerCamel.  Its values are interpreted as its value.  If value is boolean, `true` means specifying the key and `false` means not specifying.
+
+For example, `platformVersion: '9.1'` will be converted to `--platform-version=9.1`, `sessionOverride: true` will be `--session-override`, `showIosLog: false` will specify nothing.

static/js/ketcher2/node_modules/webdriverio/docs/guide/services/browserstack.md

@@ -0,0 +1,62 @@
+name: Browserstack
+category: services
+tags: guide
+index: 1
+title: WebdriverIO - Browserstack Service
+---
+
+Browserstack Service
+====================
+
+A WebdriverIO service that manages local tunnel and job metadata for Browserstack users.
+
+## Installation
+
+Simply run:
+
+```bash
+npm install --save-dev wdio-browserstack-service
+```
+
+## Configuration
+
+WebdriverIO has Browserstack support out of the box. You should simply set `user` and `key` in your `wdio.conf.js` file. This service plugin provdies supports for [Browserstack Tunnel](https://www.browserstack.com/automate/node#setting-local-tunnel). Set `browserstackLocal: true` also to activate this feature.
+
+```js
+// wdio.conf.js
+export.config = {
+  // ...
+  services: ['browserstack'],
+  user: process.env.BROWSERSTACK_USERNAME,
+  key: process.env.BROWSERSTACK_ACCESS_KEY,
+  browserstackLocal: true,
+};
+```
+
+## Options
+
+### user
+Your Browserstack username.
+
+Type: `String`
+
+### key
+Your Browserstack access key.
+
+Type: `String`
+
+### browserstackLocal
+Set this to true to enable routing connections from Browserstack cloud through your computer.
+
+Type: `Boolean`<br>
+Default: `false`
+
+### browserstackOpts
+Specified optional will be passed down to BrowserstackLocal. See [this list](https://www.browserstack.com/local-testing#modifiers) for details.
+
+Type: `Object`<br>
+Default: `{}`
+
+## Known Issues
+
+It's more of how webdriverio designed the multi-process model. It is extremely hard if not impossible to reliably transfer localIdentifier to child-processes. We recommend using it without the identifier at this moment, which will create an account-wide local tunnel.

static/js/ketcher2/node_modules/webdriverio/docs/guide/services/firefox-profile.md

@@ -0,0 +1,57 @@
+name: firefox profile
+category: services
+tags: guide
+index: 5
+title: WebdriverIO - Firefox Profile Service
+---
+
+WDIO Firefox Profile Service
+============================
+
+You want to run your Firefox browser with a specific extension or need to set couple preferences? Selenium allows you to use a profile for the Firefox browser by passing this profile as `base64` string to the `firefox_profile` property in your desired capabilities. This requires to build that profile and convert it into `base64`. This service for the [wdio testrunner](http://webdriver.io/guide/testrunner/gettingstarted.html) takes the work of compiling the profile out of your hand and let's you define your desired options comfortable from the `wdio.conf.js` file.
+
+To find all possible options just open [about:config](about:config) in your Firefox browser or go to [mozillaZine](http://kb.mozillazine.org/About:config_entries) website to find the whole documentation about each setting. In Addition to that you can define compiled (as `*.xpi`) Firefox extensions that should get installed before the test starts.
+
+## Installation
+
+The easiest way is to keep `wdio-firefox-profile-service` as a devDependency in your `package.json`.
+
+```json
+{
+  "devDependencies": {
+    "wdio-firefox-profile-service": "~0.1"
+  }
+}
+```
+
+You can simple do it by:
+
+```bash
+npm install wdio-firefox-profile-service --save-dev
+```
+
+Instructions on how to install `WebdriverIO` can be found [here.](http://webdriver.io/guide/getstarted/install.html)
+
+## Configuration
+
+Setup your profile by adding the `firefox-profile` service to your service list. Then define your settings in the `firefoxProfile` property like this:
+
+```js
+// wdio.conf.js
+export.config = {
+  // ...
+  services: ['firefox-profile'],
+  firefoxProfile: {
+      extensions: ['/path/to/extensionA.xpi', '/path/to/extensionB.xpi'],
+      'browser.startup.homepage': 'http://webdriver.io'
+  },
+  // ...
+};
+```
+
+## Options
+
+### firefoxProfile
+Contains all settings as key value pair. If you want to add an extension, use the `extensions` key with an array of string paths to the extensions you want to use.
+
+Type: `Object`

static/js/ketcher2/node_modules/webdriverio/docs/guide/services/phantomjs.md

@@ -0,0 +1,38 @@
+name: phantomjs
+category: services
+tags: guide
+index: 6
+title: WebdriverIO - PhantomJS Service
+---
+
+PhantomJS Service
+===========================
+
+[This service](https://github.com/cognitom/wdio-phantomjs-service) helps you to run PhantomJS seamlessly when running tests with the [WDIO testrunner](http://webdriver.io/guide/testrunner/gettingstarted.html). It uses [phantomjs-prebuilt](https://www.npmjs.com/package/phantomjs-prebuilt) NPM package.
+
+## Installation
+
+From npm:
+
+```bash
+npm install --save-dev wdio-phantomjs-service
+```
+
+Instructions on how to install `WebdriverIO` can be found [here.](http://webdriver.io/guide/getstarted/install.html)
+
+## Configuration
+
+In order to use the service you need to add `phantomjs` to your service array:
+
+```js
+// wdio.conf.js
+export.config = {
+  // ...
+  services: ['phantomjs'],
+  // ...
+};
+```
+
+## Examples
+
+See full examples [here](https://github.com/cognitom/webdriverio-examples/tree/master/wdio-wo-local-selenium).

static/js/ketcher2/node_modules/webdriverio/docs/guide/services/sauce.md

@@ -0,0 +1,65 @@
+name: sauce
+category: services
+tags: guide
+index: 0
+title: WebdriverIO - Sauce Service
+---
+
+Sauce Service
+=============
+
+This service helps to integrate WebdriverIO and its WDIO testrunner with the [Sauce Labs](https://saucelabs.com/) service. It automatically sets the job status for you and updates all important job properties like job name, tags, availability or custom data. Having [Sauce Connect](https://wiki.saucelabs.com/display/DOCS/Sauce+Connect+Proxy) integrated you only need some minor tweaks to your configuration to run all your tests through a secure tunnel.
+
+As stated above this service helps you to better integrate your tests with the Sauce service. One good example to show this are job annotations. These are special commands that annotate a job at a certain point of time to make it easy to find that point on the job details page.
+
+![Job Annotations](http://www.christian-bromann.com/a.png "Job Annotations")
+
+This images shows the command list on Sauce Labs job details page running [this Cucumber test](https://github.com/webdriverio/webdriverio/blob/master/examples/wdio/runner-specs/cucumber/features/my-feature.feature). The service creates automatically job annotations to help you find commands that caused failing the test quickly.
+
+## Installation
+
+In order to use the service you need to download it from NPM:
+
+```sh
+$ npm install wdio-sauce-service --save-dev
+```
+
+## Configuration
+
+In order to use the service you need to set user and key in your wdio.conf.js file. It will automatically uses Sauce Labs to run your integration tests. If you want to use Sauce Connect you just need to set sauceConnect: true.
+
+```js
+// wdio.conf.js
+export.config = {
+    // ...
+    services: ['sauce'],
+    user: process.env.SAUCE_USERNAME,
+    key: process.env.SAUCE_ACCESS_KEY,
+    sauceConnect: true,
+    // ...
+};
+```
+
+## Options
+
+### user
+Your Sauce Labs username.
+
+Type: `String`
+
+### key
+Your Sauce Labs access key.
+
+Type: `String`
+
+### sauceConnect
+If true it runs Sauce Connect and opens a secure connection between a Sauce Labs virtual machine running your browser tests.
+
+Type: `Boolean`<br>
+Default: `false`
+
+### sauceConnectOpts
+Apply Sauce Connect options (e.g. to change port number or logFile settings). See [this list](https://github.com/bermi/sauce-connect-launcher#advanced-usage) for more information.
+
+Type: `Object`<br>
+Default: `{}`

static/js/ketcher2/node_modules/webdriverio/docs/guide/services/selenium-standalone.md

@@ -0,0 +1,57 @@
+name: selenium-standalone
+category: services
+tags: guide
+index: 4
+title: WebdriverIO - Selenium Standalone Service
+---
+
+Selenium Standalone Service
+===========================
+
+Handling the Selenium server is out of scope of the actual WebdriverIO project. This service helps you to run Selenium seamlessly when running tests with the [WDIO testrunner](http://webdriver.io/guide/testrunner/gettingstarted.html). It uses the well known [selenium-standalone](https://www.npmjs.com/package/selenium-standalone) NPM package that automatically sets up the standalone server and all required drivers for you.
+
+## Installation
+
+The easiest way is to keep `wdio-selenium-standalone-service` as a devDependency in your `package.json`.
+
+```json
+{
+  "devDependencies": {
+    "wdio-selenium-standalone-service": "~0.1"
+  }
+}
+```
+
+You can simple do it by:
+
+```bash
+npm install wdio-selenium-standalone-service --save-dev
+```
+
+Instructions on how to install `WebdriverIO` can be found [here.](http://webdriver.io/guide/getstarted/install.html)
+
+## Configuration
+
+By default, Google Chrome, Firefox and PhantomJS are available when installed on the host system. In order to use the service you need to add `selenium-standalone` to your service array:
+
+```js
+// wdio.conf.js
+export.config = {
+  // ...
+  services: ['selenium-standalone'],
+  // ...
+};
+```
+
+## Options
+
+### seleniumLogs
+Path where all logs from the Selenium server should be stored.
+
+Type: `String`
+
+### seleniumArgs
+Array of arguments for the Selenium server, passed directly to `child_process.spawn`.
+
+Type: `String[]`<br>
+Default: `[]`

static/js/ketcher2/node_modules/webdriverio/docs/guide/services/static-server.md

@@ -0,0 +1,79 @@
+name: Static Server
+category: services
+tags: guide
+index: 7
+title: WebdriverIO - Static Server Service
+---
+
+# Static Server Service
+
+Some projects are front-end assets only and don't run on more than a static server. [This service](https://github.com/LeadPages/wdio-static-server-service) helps you to run a static file server during testing.
+
+## Installation
+
+The easiest way is to keep `wdio-static-server-service` as a devDependency in your `package.json`.
+
+```json
+{
+  "devDependencies": {
+    "wdio-static-server-service": "^1.0.0"
+  }
+}
+```
+
+You can simple do it by:
+
+```bash
+npm install wdio-static-server-service --save-dev
+```
+
+Instructions on how to install `WebdriverIO` can be found [here.](http://webdriver.io/guide/getstarted/install.html)
+
+## Configuration
+
+In order to use the static server service you need to add `static-server` to your service array:
+
+```js
+// wdio.conf.js
+export.config = {
+  // ...
+  services: ['static-server'],
+  // ...
+};
+```
+
+## Options
+
+### staticServerFolders (required)
+Array of folder paths and mount points.
+
+Type: `Array<Object>`
+Props:
+ - mount `{String}` - URL endpoint where folder will be mounted.
+ - path `{String}` - Path to the folder to mount.
+
+``` javascript
+ // wdio.conf.js
+ export.config = {
+   // ...
+   staticServerFolders: [
+     { mount: '/fixtures', path: './tests/fixtures' },
+     { mount: '/dist', path: './dist' },
+   ],
+   // ...
+ };
+```
+
+### staticServerPort
+
+Port to bind the server.
+
+Type: `Number`
+
+Default: `4567`
+
+### staticServerLog
+
+Debugging logs, will print mount points and requests. When `staticServerLogs` is set to `true` it will print into the console. Otherwise a string will be treated as the log folder.
+
+Type: `Boolean` or `String`

static/js/ketcher2/node_modules/webdriverio/docs/guide/services/testingbot.md

@@ -0,0 +1,59 @@
+name: TestingBot
+category: services
+tags: guide
+index: 2
+title: WebdriverIO - TestingBot Service
+---
+
+TestingBot Service
+==================
+
+A WebdriverIO service. It updates the job metadata ('name', 'passed', 'tags', 'public', 'build', 'extra') and runs TestingBot Tunnel if desired.
+
+## Installation
+
+In order to use the service you need to download it from NPM:
+
+```sh
+$ npm install wdio-testingbot-service --save-dev
+```
+
+## Configuration
+
+In order to use the service you need to set user and key in your `wdio.conf.js` file, and set the `host` option to `hub.testingbot.com`. If you want to use [TestingBot Tunnel](https://testingbot.com/support/other/tunnel) you just need to set `tbTunnel: true`.
+
+```js
+// wdio.conf.js
+export.config = {
+    // ...
+    services: ['testingbot'],
+    user: process.env.TB_KEY,
+    key: process.env.TB_SECRET,
+    tbTunnel: true,
+    // ...
+};
+```
+
+## Options
+
+### user
+Your TestingBot API KEY.
+
+Type: `String`
+
+### key
+Your TestingBot API SECRET.
+
+Type: `String`
+
+### tbTunnel
+If true it runs the TestingBot Tunnel and opens a secure connection between a TestingBot Virtual Machine running your browser tests.
+
+Type: `Boolean`<br>
+Default: `false`
+
+### tbTunnelOpts
+Apply TestingBot Tunnel options (e.g. to change port number or logFile settings). See [this list](https://github.com/testingbot/testingbot-tunnel-launcher) for more information.
+
+Type: `Object`<br>
+Default: `{}`

static/js/ketcher2/node_modules/webdriverio/docs/guide/services/visual-regression.md

@@ -0,0 +1,148 @@
+name: Visual Regression
+category: services
+tags: guide
+index: 8
+title: WebdriverIO - Visual Regression Service
+---
+
+Visual Regression Service
+=========================
+
+> Visual regression testing with WebdriverIO.
+
+## Installation
+
+wdio-visual-regression-service uses [wdio-screenshot](https://github.com/zinserjan/wdio-screenshot) for capturing screenhots.
+
+You can install wdio-visual-regression-service via NPM as usual:
+
+```sh
+$ npm install wdio-visual-regression-service --save-dev
+```
+
+Instructions on how to install `WebdriverIO` can be found [here.](http://webdriver.io/guide/getstarted/install.html)
+
+An example repository using the wdio-visual-regression service can be found [here.](https://github.com/zinserjan/webdriverio-example)
+
+## Configuration
+Setup wdio-visual-regression-service by adding `visual-regression` to the service section of your WebdriverIO config and define your desired comparison strategy in `visualRegression`.
+
+```js
+// wdio.conf.js
+
+var path = require('path');
+var VisualRegressionCompare = require('wdio-visual-regression-service/compare');
+
+function getScreenshotName(basePath) {
+  return function(context) {
+    var type = context.type;
+    var testName = context.test.title;
+    var browserVersion = parseInt(context.browser.version, 10);
+    var browserName = context.browser.name;
+    var browserWidth = context.meta.width;
+
+    return path.join(basePath, `${testName}_${type}_${browserName}_v${browserVersion}_${browserWidth}.png`);
+  };
+}
+
+exports.config = {
+  // ...
+  services: [
+    'visual-regression',
+  ],
+  visualRegression: {
+    compare: new VisualRegressionCompare.LocalCompare({
+      referenceName: getScreenshotName(path.join(process.cwd(), 'screenshots/reference')),
+      screenshotName: getScreenshotName(path.join(process.cwd(), 'screenshots/screen')),
+      diffName: getScreenshotName(path.join(process.cwd(), 'screenshots/diff')),
+      misMatchTolerance: 0.01,
+    }),
+    viewportChangePause: 300,
+    widths: [320, 480, 640, 1024],
+    orientations: ['landscape', 'portrait'],
+  },
+  // ...
+};
+```
+
+### Options
+Under the key `visualRegression` in your wdio.config.js you can pass a configuration object with the following structure:
+
+* **compare** `Object` <br>
+screenshot compare method, see [Compare Methods](#compare-methods)
+
+* **viewportChangePause**  `Number`  ( default: 100 ) <br>
+wait x milliseconds after viewport change. It can take a while for the browser to re-paint. This could lead to rendering issues and produces inconsistent results between runs.
+
+* **widths** `Number[]`  ( default: *[current-width]* ) (**desktop only**)<br>
+   all screenshots will be taken in different screen widths (e.g. for responsive design tests)
+
+* **orientations** `String[] {landscape, portrait}`  ( default: *[current-orientation]* ) (**mobile only**)<br>
+    all screenshots will be taken in different screen orientations (e.g. for responsive design tests)
+
+### Compare Methods
+wdio-visual-regression-service allows the usage of different screenshot comparison methods.
+
+#### VisualRegressionCompare.LocalCompare
+As it's name suggests *LocalCompare* captures screenshots locally on your computer and compares them against previous runs.
+
+You can pass the following options to it's constructor as object:
+
+* **referenceName** `Function` <br>
+pass in a function that returns the filename for the reference screenshot. Function receives a *context* object as first parameter with all relevant information about the command.
+
+* **screenshotName** `Function` <br>
+pass in a function that returns the filename for the current screenshot. Function receives a *context* object as first parameter with all relevant information about the command.
+
+* **diffName** `Function` <br>
+pass in a function that returns the filename for the diff screenshot. Function receives a *context* object as first parameter with all relevant information about the command.
+
+* **misMatchTolerance** `Number`  ( default: 0.01 ) <br>
+number between 0 and 100 that defines the degree of mismatch to consider two images as identical, increasing this value will decrease test coverage.
+
+For an example of generating screenshot filesnames dependent on the current test name, have a look at the sample code of [Configuration](#configuration).
+
+#### VisualRegressionCompare.SaveScreenshot
+This method is a stripped variant of `VisualRegressionCompare.LocalCompare` to capture only screenshots. This is quite useful when you just want to create reference screenshots and overwrite the previous one without diffing.
+
+You can pass the following options to it's constructor as object:
+
+* **screenshotName** `Function` <br>
+pass in a function that returns the filename for the current screenshot. Function receives a *context* object as first parameter with all relevant information about the command.
+
+## Usage
+wdio-visual-regression-service enhances an WebdriverIO instance with the following commands:
+* `browser.checkViewport([{options}]);`
+* `browser.checkDocument([{options}]);`
+* `browser.checkElement(elementSelector, [{options}]);`
+
+
+All of these provide options that will help you to capture screenshots in different dimensions or to exclude unrelevant parts (e.g. content). The following options are
+available:
+
+
+* **exclude** `String[]|Object[]` (**not yet implemented**)<br>
+  exclude frequently changing parts of your screenshot, you can either pass all kinds of different [WebdriverIO selector strategies](http://webdriver.io/guide/usage/selectors.html)
+  that queries one or multiple elements or you can define x and y values which stretch a rectangle or polygon
+
+* **hide** `String[]`<br>
+  hides all elements queried by all kinds of different [WebdriverIO selector strategies](http://webdriver.io/guide/usage/selectors.html) (via `visibility: hidden`)
+
+* **remove** `String[]`<br>
+  removes all elements queried by all kinds of different [WebdriverIO selector strategies](http://webdriver.io/guide/usage/selectors.html) (via `display: none`)
+
+* **widths** `Number[]` (**desktop only**)<br>
+     Overrides the global *widths* value for this command. All screenshots will be taken in different screen widths (e.g. for responsive design tests)
+
+* **orientations** `String[] {landscape, portrait}` (**mobile only**)<br>
+    Overrides the global *orientations* value for this command. All screenshots will be taken in different screen orientations (e.g. for responsive design tests)
+
+* **misMatchTolerance** `Number` <br>
+    Overrides the global *misMatchTolerance* value for this command. Pass in a number between 0 and 100 that defines the degree of mismatch to consider two images as identical,
+
+* **viewportChangePause**  `Number` <br>
+    Overrides the global *viewportChangePause* value for this command. Wait x milliseconds after viewport change.
+
+### License
+
+MIT

static/js/ketcher2/node_modules/webdriverio/docs/guide/services/webpack-dev-server

@@ -0,0 +1,63 @@
+name: Webpack Dev Server
+category: services
+tags: guide
+index: 9
+title: WebdriverIO - Webpack Dev Server Service
+---
+
+WDIO Webpack Dev Server Service
+====================
+
+This allows you to run a local server with your built static assets using Webpack Dev Server before testing.
+
+## Installation
+
+``bash
+npm install wdio-webpack-dev-server-service --save-dev
+```
+
+## Configuration
+
+This assumes you have:
+
+- [set up WebdriverIO](https://webdriver.io/guide.html).
+- [set up Webpack Dev Server](https://webpack.js.org/guides/development/#webpack-dev-server) - the example will use `webpack.dev.config.js` as the configuration file.
+
+Add the Webpack Dev Server service to your WebdriverIO services list:
+
+```js
+// wdio.conf.js
+export.config = {
+  // ...
+  services: ['webpack-dev-server'],
+  // ...
+};
+```
+
+Options are set directly on your WebdriverIO config as well, e.g.
+
+```js
+// wdio.conf.js
+export.config = {
+  // ...
+  webpackConfig: require('webpack.dev.config.js'),
+  webpackPort: 8080,
+  // ...
+};
+```
+
+## Options
+
+### `webpackConfig`
+Type: `String` | `Object`
+
+Default: `webpack.config.js`
+
+Either the absolute path to your Webpack configuration, or your actual Webpack configuration.
+
+### `webpackPort`
+Type: Number
+
+Default: `8080`
+
+The port the Dev Server should be run on. You'll want to set this same port in the `baseUrl` option of your WebdriverIO configuration.

static/js/ketcher2/node_modules/webdriverio/docs/guide/services/webpack.md

@@ -0,0 +1,64 @@
+name: Webpack
+category: services
+tags: guide
+index: 8
+title: WebdriverIO - Webpack Service
+---
+
+WDIO Webpack Service
+====================
+
+This allows you to build your static assets through webpack before testing.
+
+## Installation
+
+The easiest way is to keep `wdio-webpack-service` as a devDependency in your `package.json`.
+
+```json
+{
+  "devDependencies": {
+    "wdio-webpack-service": "^1.0.0"
+  }
+}
+```
+
+You can simple do it by:
+
+```bash
+npm install wdio-webpack-service --save-dev
+```
+
+Instructions on how to install `WebdriverIO` can be found [here.](http://webdriver.io/guide/getstarted/install.html)
+
+## Configuration
+
+In order to use the static server service you need to add `webpack` to your service array:
+
+```js
+// wdio.conf.js
+export.config = {
+  // ...
+  services: ['webpack'],
+  // ...
+};
+```
+
+## Options
+
+### webpackConfig (required)
+
+The configuration for webpack to use in order to build the bundle. See [webpack's documentation](http://webpack.github.io/docs/configuration.html) for more information.
+
+Type: `Object`
+
+### webpackDriverConfig
+
+This option lets you override some of the settings in you webpack config for the driver. You can use this to change things like where the files are placed. The configurations are merged using the [`webpack-merge`](https://github.com/survivejs/webpack-merge) project and the smart strategy.
+
+Type: `Object`
+
+### webpackLog
+
+Debugging logs, will print mount points and requests. When `webpackLogs` is set to `true` it will print into the console. Otherwise a string will be treated as the log folder.
+
+Type: `Boolean` or `String`

static/js/ketcher2/node_modules/webdriverio/docs/guide/testrunner/browserobject.md

@@ -0,0 +1,87 @@
+name: The Browser Object
+category: testrunner
+tags: guide
+index: 3
+title: WebdriverIO - The Browser Object
+---
+
+The Browser Object
+==================
+
+If you use the wdio test runner you can access the webdriver instance through the global `browser` object. The session is initialized by the test runner so you don't need to call [`init`](/api/protocol/init.html) command. The same goes for ending the session. This is also done by the test runner process.
+
+Besides all commands from the [api](/api.html) the browser object provides some more information you might be interested in during your test run:
+
+### Get desired capabilities
+
+```js
+console.log(browser.desiredCapabilities);
+/**
+ * outputs:
+ * {
+       javascriptEnabled: true,
+       locationContextEnabled: true,
+       handlesAlerts: true,
+       rotatable: true,
+       browserName: 'chrome',
+       loggingPrefs: { browser: 'ALL', driver: 'ALL' }
+   }
+ */
+```
+
+### Get wdio config options
+
+```js
+// wdio.conf.js
+exports.config = {
+    // ...
+    foobar: true,
+    // ...
+}
+```
+
+```js
+console.log(browser.options);
+/**
+ * outputs:
+ * {
+        port: 4444,
+        protocol: 'http',
+        waitforTimeout: 10000,
+        waitforInterval: 250,
+        coloredLogs: true,
+        logLevel: 'verbose',
+        baseUrl: 'http://localhost',
+        connectionRetryTimeout: 90000,
+        connectionRetryCount: 3,
+        sync: true,
+        specs: [ 'err.js' ],
+        foobar: true, // <-- custom option
+        // ...
+ */
+```
+
+### Check if capability is a mobile device
+
+```js
+var client = require('webdriverio').remote({
+    desiredCapabilities: {
+    	platformName: 'iOS',
+        app: 'net.company.SafariLauncher',
+        udid: '123123123123abc',
+        deviceName: 'iPhone',
+    }
+});
+
+console.log(client.isMobile); // outputs: true
+console.log(client.isIOS); // outputs: true
+console.log(client.isAndroid); // outputs: false
+```
+
+### Log results
+
+```js
+browser.logger.info('some random logging');
+```
+
+For more information about the logger class check out [Logger.js](https://github.com/webdriverio/webdriverio/blob/master/lib/utils/Logger.js) on GitHub.

static/js/ketcher2/node_modules/webdriverio/docs/guide/testrunner/configurationfile.md

@@ -0,0 +1,349 @@
+name: configurationfile
+category: testrunner
+tags: guide
+index: 1
+title: WebdriverIO - Test Runner Configuration File
+---
+
+Configuration File
+==================
+
+The configuration file contains all necessary information to run your test suite. It is a node module that exports a JSON. Here is an example configuration with all supported properties and additional information:
+
+```js
+exports.config = {
+
+    // =====================
+    // Server Configurations
+    // =====================
+    // Host address of the running Selenium server. This information is usually obsolete as
+    // WebdriverIO automatically connects to localhost. Also if you are using one of the
+    // supported cloud services like Sauce Labs, Browserstack or Testing Bot you also don't
+    // need to define host and port information because WebdriverIO can figure that out
+    // according to your user and key information. However if you are using a private Selenium
+    // backend you should define the host address, port, and path here.
+    //
+    host: '0.0.0.0',
+    port: 4444,
+    path: '/wd/hub',
+    //
+    // =================
+    // Service Providers
+    // =================
+    // WebdriverIO supports Sauce Labs, Browserstack and Testing Bot (other cloud providers
+    // should work too though). These services define specific user and key (or access key)
+    // values you need to put in here in order to connect to these services.
+    //
+    user: 'webdriverio',
+    key:  'xxxxxxxxxxxxxxxx-xxxxxx-xxxxx-xxxxxxxxx',
+    //
+    // ==================
+    // Specify Test Files
+    // ==================
+    // Define which test specs should run. The pattern is relative to the directory
+    // from which `wdio` was called. Notice that, if you are calling `wdio` from an
+    // NPM script (see https://docs.npmjs.com/cli/run-script) then the current working
+    // directory is where your package.json resides, so `wdio` will be called from there.
+    //
+    specs: [
+        'test/spec/**'
+    ],
+    // Patterns to exclude.
+    exclude: [
+        'test/spec/multibrowser/**',
+        'test/spec/mobile/**'
+    ],
+    //
+    // ============
+    // Capabilities
+    // ============
+    // Define your capabilities here. WebdriverIO can run multiple capabilities at the same
+    // time. Depending on the number of capabilities, WebdriverIO launches several test
+    // sessions. Within your capabilities you can overwrite the spec and exclude option in
+    // order to group specific specs to a specific capability.
+    //
+    //
+    // First you can define how many instances should be started at the same time. Let's
+    // say you have 3 different capabilities (Chrome, Firefox and Safari) and you have
+    // set maxInstances to 1, wdio will spawn 3 processes. Therefor if you have 10 spec
+    // files and you set maxInstances to 10, all spec files will get tested at the same time
+    // and 30 processes will get spawned. The property basically handles how many capabilities
+    // from the same test should run tests.
+    //
+    //
+    maxInstances: 10,
+    //
+    // If you have trouble getting all important capabilities together, check out the
+    // Sauce Labs platform configurator - a great tool to configure your capabilities:
+    // https://docs.saucelabs.com/reference/platforms-configurator
+    //
+    capabilities: [{
+        browserName: 'chrome'
+    }, {
+        // maxInstances can get overwritten per capability. So if you have an in house Selenium
+        // grid with only 5 firefox instance available you can make sure that not more than
+        // 5 instance gets started at a time.
+        maxInstances: 5,
+        browserName: 'firefox',
+        specs: [
+            'test/ffOnly/*'
+        ]
+    },{
+        browserName: 'phantomjs',
+        exclude: [
+            'test/spec/alert.js'
+        ]
+    }],
+    //
+    // When enabled opens a debug port for node-inspector and pauses execution
+    // on `debugger` statements. The node-inspector can be attached with:
+    // `node-inspector --debug-port 5859 --no-preload`
+    // When debugging it is also recommended to change the timeout interval of
+    // test runner (eg. jasmineNodeOpts.defaultTimeoutInterval) to a very high
+    // value and setting maxInstances to 1.
+    debug: false,
+    //
+    // Additional list node arguments to use when starting child processes
+    execArgv: null,
+    //
+    //
+    // ===================
+    // Test Configurations
+    // ===================
+    // Define all options that are relevant for the WebdriverIO instance here
+    //
+    // Per default WebdriverIO commands getting executed in a synchronous way using
+    // the wdio-sync package. If you still want to run your tests in an async way
+    // using promises you can set the sync command to false.
+    sync: true,
+    //
+    // Level of logging verbosity: silent | verbose | command | data | result | error
+    logLevel: 'silent',
+    //
+    // Enables colors for log output.
+    coloredLogs: true,
+    //
+    // If you only want to run your tests until a specific amount of tests have failed use
+    // bail (default is 0 - don't bail, run all tests).
+    bail: 0,
+    //
+    // Saves a screenshot to a given path if a command fails.
+    screenshotPath: 'shots',
+    //
+    // Set a base URL in order to shorten url command calls. If your url parameter starts
+    //  with "/", the base url gets prepended.
+    baseUrl: 'http://localhost:9090',
+    //
+    // Default timeout for all waitForXXX commands.
+    waitforTimeout: 1000,
+    //
+    // Initialize the browser instance with a WebdriverIO plugin. The object should have the
+    // plugin name as key and the desired plugin options as property. Make sure you have
+    // the plugin installed before running any tests. The following plugins are currently
+    // available:
+    // WebdriverCSS: https://github.com/webdriverio/webdrivercss
+    // WebdriverRTC: https://github.com/webdriverio/webdriverrtc
+    // Browserevent: https://github.com/webdriverio/browserevent
+    plugins: {
+        webdrivercss: {
+            screenshotRoot: 'my-shots',
+            failedComparisonsRoot: 'diffs',
+            misMatchTolerance: 0.05,
+            screenWidth: [320,480,640,1024]
+        },
+        webdriverrtc: {},
+        browserevent: {}
+    },
+    //
+    // Framework you want to run your specs with.
+    // The following are supported: mocha, jasmine and cucumber
+    // see also: http://webdriver.io/guide/testrunner/frameworks.html
+    //
+    // Make sure you have the wdio adapter package for the specific framework installed before running any tests.
+    framework: 'mocha',
+    //
+    // Test reporter for stdout.
+    // The only one supported by default is 'dot'
+    // see also: http://webdriver.io/guide.html and click on "Reporters" in left column
+    reporters: ['dot', 'allure'],
+    //
+    // Some reporter require additional information which should get defined here
+    reporterOptions: {
+        //
+        // If you are using the "xunit" reporter you should define the directory where
+        // WebdriverIO should save all unit reports.
+        outputDir: './'
+    },
+    //
+    // Options to be passed to Mocha.
+    // See the full list at http://mochajs.org/
+    mochaOpts: {
+        ui: 'bdd'
+    },
+    //
+    // Options to be passed to Jasmine.
+    // See also: https://github.com/webdriverio/wdio-jasmine-framework#jasminenodeopts-options
+    jasmineNodeOpts: {
+        //
+        // Jasmine default timeout
+        defaultTimeoutInterval: 5000,
+        //
+        // The Jasmine framework allows it to intercept each assertion in order to log the state of the application
+        // or website depending on the result. For example it is pretty handy to take a screenshot every time
+        // an assertion fails.
+        expectationResultHandler: function(passed, assertion) {
+            // do something
+        },
+        //
+        // Make use of Jasmine-specific grep functionality
+        grep: null,
+        invertGrep: null
+    },
+    //
+    // If you are using Cucumber you need to specify where your step definitions are located.
+    // See also: https://github.com/webdriverio/wdio-cucumber-framework#cucumberopts-options
+    cucumberOpts: {
+        require: [],        // <string[]> (file/dir) require files before executing features
+        backtrace: false,   // <boolean> show full backtrace for errors
+        compiler: [],       // <string[]> ("extension:module") require files with the given EXTENSION after requiring MODULE (repeatable)
+        dryRun: false,      // <boolean> invoke formatters without executing steps
+        failFast: false,    // <boolean> abort the run on first failure
+        format: ['pretty'], // <string[]> (type[:path]) specify the output format, optionally supply PATH to redirect formatter output (repeatable)
+        colors: true,       // <boolean> disable colors in formatter output
+        snippets: true,     // <boolean> hide step definition snippets for pending steps
+        source: true,       // <boolean> hide source URIs
+        profile: [],        // <string[]> (name) specify the profile to use
+        strict: false,      // <boolean> fail if there are any undefined or pending steps
+        tags: [],           // <string[]> (expression) only execute the features or scenarios with tags matching the expression
+        timeout: 20000,      // <number> timeout for step definitions
+        ignoreUndefinedDefinitions: false, // <boolean> Enable this config to treat undefined definitions as warnings.
+    },
+    //
+    // =====
+    // Hooks
+    // =====
+    // WebdriverIO provides a several hooks you can use to interfere the test process in order to enhance
+    // it and build services around it. You can either apply a single function to it or an array of
+    // methods. If one of them returns with a promise, WebdriverIO will wait until that promise got
+    // resolved to continue.
+    //
+
+    /**
+     * Gets executed once before all workers get launched.
+     * @param {Object} config wdio configuration object
+     * @param {Array.<Object>} capabilities list of capabilities details
+     */
+    onPrepare: function (config, capabilities) {
+    },
+    /**
+     * Gets executed just before initialising the webdriver session and test framework. It allows you
+     * to manipulate configurations depending on the capability or spec.
+     * @param {Object} config wdio configuration object
+     * @param {Array.<Object>} capabilities list of capabilities details
+     * @param {Array.<String>} specs List of spec file paths that are to be run
+     */
+    beforeSession: function (config, capabilities, specs) {
+    },  
+    /**
+     * Gets executed before test execution begins. At this point you can access to all global
+     * variables like `browser`. It is the perfect place to define custom commands.
+     * @param {Array.<Object>} capabilities list of capabilities details
+     * @param {Array.<String>} specs List of spec file paths that are to be run
+     */
+    before: function (capabilities, specs) {
+    },
+    /**
+     * Hook that gets executed before the suite starts
+     * @param {Object} suite suite details
+     */
+    beforeSuite: function (suite) {
+    },
+    /**
+     * Hook that gets executed _before_ a hook within the suite starts (e.g. runs before calling
+     * beforeEach in Mocha)
+     */
+    beforeHook: function () {
+    },
+    /**
+     * Hook that gets executed _after_ a hook within the suite starts (e.g. runs after calling
+     * afterEach in Mocha)
+     */
+    afterHook: function () {
+    },
+    /**
+     * Function to be executed before a test (in Mocha/Jasmine) or a step (in Cucumber) starts.
+     * @param {Object} test test details
+     */
+    beforeTest: function (test) {
+    },
+    /**
+     * Runs before a WebdriverIO command gets executed.
+     * @param {String} commandName hook command name
+     * @param {Array} args arguments that command would receive
+     */
+    beforeCommand: function (commandName, args) {
+    },
+    /**
+     * Runs after a WebdriverIO command gets executed
+     * @param {String} commandName hook command name
+     * @param {Array} args arguments that command would receive
+     * @param {Number} result 0 - command success, 1 - command error
+     * @param {Object} error error object if any
+     */
+    afterCommand: function (commandName, args, result, error) {
+    },
+    /**
+     * Function to be executed after a test (in Mocha/Jasmine) or a step (in Cucumber) starts.
+     * @param {Object} test test details
+     */
+    afterTest: function (test) {
+    },
+    /**
+     * Hook that gets executed after the suite has ended
+     * @param {Object} suite suite details
+     */
+    afterSuite: function (suite) {
+    },
+    /**
+     * Gets executed after all tests are done. You still have access to all global variables from
+     * the test.
+     * @param {Number} result 0 - test pass, 1 - test fail
+     * @param {Array.<Object>} capabilities list of capabilities details
+     * @param {Array.<String>} specs List of spec file paths that ran
+     */
+    after: function (result, capabilities, specs) {
+    },
+    /**
+     * Gets executed right after terminating the webdriver session.
+     * @param {Object} config wdio configuration object
+     * @param {Array.<Object>} capabilities list of capabilities details
+     * @param {Array.<String>} specs List of spec file paths that ran
+     */
+    afterSession: function (config, capabilities, specs) {
+    },
+    /**
+     * Gets executed after all workers got shut down and the process is about to exit.
+     * @param {Object} exitCode 0 - success, 1 - fail
+     * @param {Object} config wdio configuration object
+     * @param {Array.<Object>} capabilities list of capabilities details
+     */
+    onComplete: function (exitCode, config, capabilities) {
+    },
+    //
+    // Cucumber specific hooks
+    beforeFeature: function (feature) {
+    },
+    beforeScenario: function (scenario) {
+    },
+    beforeStep: function (step) {
+    },
+    afterStep: function (stepResult) {
+    },
+    afterScenario: function (scenario) {
+    },
+    afterFeature: function (feature) {
+    }
+};
+```
+
+You can also find that file with all possible options and variations in the [example folder](https://github.com/webdriverio/webdriverio/blob/master/examples/wdio.conf.js).

static/js/ketcher2/node_modules/webdriverio/docs/guide/testrunner/debugging.md

@@ -0,0 +1,132 @@
+name: Debugging
+category: testrunner
+tags: guide
+index: 8
+title: WebdriverIO - Test Runner Frameworks
+---
+
+Debugging
+==========
+
+Debugging is significantly more difficult when there are several processes spawning dozens of tests in multiple browsers.
+
+For starters, it is extremely helpful to limit parallelism by setting `maxInstances` to 1 and targeting only those specs and browsers that need to be debugged.
+
+
+In `wdio.conf`:
+```
+maxInstances: 1,
+specs: ['**/myspec.spec.js'],
+capabilities: [{browserName: 'firefox'}]
+```
+
+In many cases, you can use [`browser.debug()`](/api/utility/debug.html) to pause your test and inspect the browser. Your command line interface will also switch into a REPL mode that allows you to fiddle around with commands and elements on the page. In REPL mode you can access the browser object or `$` and `$$` functions like you can in your tests.
+
+When using `browser.debug()` you will likely need to increase the timeout of the test runner to prevent the test runner from failing the test for taking to long.  For example:
+
+In `wdio.conf`:
+```
+jasmineNodeOpts: {
+  defaultTimeoutInterval: (24 * 60 * 60 * 1000);
+}
+```
+
+See [timeouts](/guide/testrunner/timeouts.html) for more information on how to do that using other frameworks.
+
+## Watch files
+
+With `v4.6.0` WebdriverIO introduced a watch argument that can help you to run certain specs when they get updated. To enable it just run the wdio command with the watch flag like:
+
+```sh
+wdio wdio.conf.js --watch
+```
+
+It will initialize the desired Selenium sessions defined in your config and will wait until a file that was defined via the `specs` option has changed. This works regardless you run your tests on a local grid or on cloud services like [SauceLabs](https://saucelabs.com/).
+
+## Node Inspector
+
+**n.b. If you are using Node v6.3 and above, you should use Node's built-in debugger, instead. [See below](#node_debugger)**
+
+For a more comprehensive debugging experience you can enable debug flag to start the test runner processes with an open debugger port.
+
+This will allow attaching the node-inspector and pausing test execution with `debugger`.  Each child process will be assigned a new debugging port starting at `5859`.
+
+This feature can be enabled by enabling the `debug` flag in wdio.conf:
+
+```
+{
+  debug: true
+}
+```
+
+Once enabled tests will pause at `debugger` statements. You then must attach the debugger to continue.
+
+If you do not already have `node-inspector` installed, install it with:
+```
+npm install -g node-inspector
+```
+
+And attach to the process with:
+```
+node-inspector --debug-port 5859 --no-preload
+```
+
+The `no-preload` option defers loading source file until needed, this helps performance significantly when project contains a large number of node_modules, but you may need to remove this if you need to navigate your source and add additional breakpoints after attaching the debugger.
+
+## Node built-in debugging with chrome-devtools<a id="node_debugger"></a>
+
+Chrome devtool debugging looks like it's going to be the accepted replacement for node-inspector. This quote is from the node-inspector github README:
+
+> Since version 6.3, Node.js provides a buit-in DevTools-based debugger which mostly deprecates Node Inspector, see e.g. this blog post to get started. The built-in debugger is developed directly by the V8/Chromium team and provides certain advanced features (e.g. long/async stack traces) that are too difficult to implement in Node Inspector.
+
+To get it working, you need to pass the `--inspect` flag down to the node process running tests like this:
+
+In `wdio.conf`:
+```
+execArgv: ['--inspect']
+```
+
+You should see a message something like this in console:
+```
+Debugger listening on port 9229.
+Warning: This is an experimental feature and could change at any time.
+To start debugging, open the following URL in Chrome:
+    chrome-devtools://devtools/remote/serve_file/@60cd6e859b9f557d2312f5bf532...
+```
+You'll want to open that url, which will attach the debugger.
+
+Tests will pause at `debugger` statements, but ONLY once dev-tools has been opened and the debugger attached. That can be a little awkward if you're trying to debug something close to the start of a test.
+You can get around that by adding a `browser.debug()` to pause long enough.
+
+Once execution has finished, the test doesn't actually finish until the devtools is closed. You'll need to do that yourself.
+
+## Dynamic configuration
+
+Note that `wdio.conf` can contain javascript. Since you probably do not want to permanently change your timeout value to 1 day, it can be often helpful to change these settings from the command line using an environment variable. This can used to dynamically change the configuration:
+
+```
+var debug = process.env.DEBUG;
+var defaultCapabilities = ...;
+var defaultTimeoutInterval = ...;
+var defaultSpecs = ...;
+
+
+exports.config = {
+debug: debug,
+maxInstances: debug ? 1 : 100,
+capabilities: debug ? [{browserName: 'chrome'}] : defaultCapabilities,
+specs:  process.env.SPEC ? [process.env.SPEC] : defaultSepcs,
+jasmineNodeOpts: {
+  defaultTimeoutInterval: debug ? (24 * 60 * 60 * 1000) : defaultTimeoutInterval
+}
+
+```
+
+You can then prefix the `wdio` command with your desired values:
+```
+DEBUG=true SPEC=myspec ./node_modules/.bin/wdio wdio.conf
+```
+
+## Dynamic Repl with Atom
+
+If you are an [Atom](https://atom.io/) hacker you can try [wdio-repl](https://github.com/kurtharriger/wdio-repl) by [@kurtharriger](https://github.com/kurtharriger) which is a dynamic repl that allows you to execute single code lines in Atom. Watch [this](https://www.youtube.com/watch?v=kdM05ChhLQE) Youtube video to see a demo.

static/js/ketcher2/node_modules/webdriverio/docs/guide/testrunner/frameworks.md

@@ -0,0 +1,113 @@
+name: frameworks
+category: testrunner
+tags: guide
+index: 2
+title: WebdriverIO - Test Runner Frameworks
+---
+
+Frameworks
+==========
+
+The wdio runner currently supports [Mocha](http://mochajs.org/), [Jasmine](http://jasmine.github.io/) (v2.0) and [Cucumber](https://cucumber.io/). To integrate each framework with WebdriverIO there are adapter packages on NPM that need to be downloaded and installed. Note that these packages need to be installed at the same place WebdriverIO is installed. If you've installed WebdriverIO globally make sure you have the adapter package installed globally as well.
+
+Within your spec files or step definition you can access the webdriver instance using the global variable `browser`. You don't need to initiate or end the Selenium session. This is taken care of by the wdio testrunner.
+
+## Using Mocha
+
+First you need to install the adapter package from NPM:
+
+```sh
+npm install wdio-mocha-framework --save-dev
+```
+
+If you like to use Mocha you should additionally install an assertion library to have more expressive tests, e.g. [Chai](http://chaijs.com). Initialise that library in the `before` hook in your configuration file:
+
+```js
+before: function() {
+    var chai = require('chai');
+    global.expect = chai.expect;
+    chai.Should();
+}
+```
+
+Once that is done you can write beautiful assertions like:
+
+```js
+describe('my awesome website', function() {
+    it('should do some chai assertions', function() {
+        browser.url('http://webdriver.io');
+        browser.getTitle().should.be.equal('WebdriverIO - WebDriver bindings for Node.js');
+    });
+});
+```
+
+WebdriverIO supports Mochas `BDD` (default), `TDD` and `QUnit` [interface](https://mochajs.org/#interfaces). If you like to write your specs in TDD language set the ui property in your `mochaOpts` config to `tdd`, now your test files should get written like:
+
+```js
+suite('my awesome website', function() {
+    test('should do some chai assertions', function() {
+        browser.url('http://webdriver.io');
+        browser.getTitle().should.be.equal('WebdriverIO - WebDriver bindings for Node.js');
+    });
+});
+```
+
+If you want to define specific Mocha settings you can do that by adding `mochaOpts` to your configuration file. A list of all options can be found on the [project website](http://mochajs.org/).
+
+Note that since all commands are running synchronously there is no need to have async mode in Mocha enabled. Therefor you can't use the `done` callback:
+
+```js
+it('should test something', function () {
+    done(); // throws "done is not a function"
+})
+```
+
+If you want to run something asynchronously you can either use the [`call`](/api/utility/call.html) command or [custom commands](/guide/usage/customcommands.html).
+
+## Using Jasmine
+
+First you need to install the adapter package from NPM:
+
+```sh
+npm install wdio-jasmine-framework --save-dev
+```
+
+Jasmine already provides assertion methods you can use with WebdriverIO. So there is no need to add another one.
+
+### Intercept Assertion
+
+The Jasmine framework allows it to intercept each assertion in order to log the state of the application or website depending on the result. For example it is pretty handy to take a screenshot everytime an assertion fails. In your `jasmineNodeOpts` you can add a property called `expectationResultHandler` that takes a function to execute. The function parameter give you information about the result of the assertion. The following example demonstrate how to take a screenshot if an assertion fails:
+
+```js
+jasmineNodeOpts: {
+    defaultTimeoutInterval: 10000,
+    expectationResultHandler: function(passed, assertion) {
+        /**
+         * only take screenshot if assertion failed
+         */
+        if(passed) {
+            return;
+        }
+
+        browser.saveScreenshot('assertionError_' + assertion.error.message + '.png');
+    }
+},
+```
+
+Please note that you can't stop the test execution to do something async. It might happen that
+the command takes too much time and the website state has changed. Though usually after 2 another
+commands the screenshot got taken which gives you still valuable information about the error.
+
+## Using Cucumber
+
+First you need to install the adapter package from NPM:
+
+```sh
+npm install wdio-cucumber-framework --save-dev
+```
+
+If you want to use Cucumber set the `framework` property to cucumber, either by adding `framework: 'cucumber'` to the [config file](/guide/testrunner/configurationfile.html) or by adding `-f cucumber` to the command line.
+
+Options for Cucumber can be given in the config file with cucumberOpts. Check out the whole list of options [here](https://github.com/webdriverio/wdio-cucumber-framework#cucumberopts-options).
+
+To get up and running quickly with Cucumber have a look on our [cucumber-boilerplate](https://github.com/webdriverio/cucumber-boilerplate) project that comes with all step definition you will probably need and allows you to start writing feature files right away.

static/js/ketcher2/node_modules/webdriverio/docs/guide/testrunner/gettingstarted.md

@@ -0,0 +1,90 @@
+name: gettingstarted
+category: testrunner
+tags: guide
+index: 0
+title: WebdriverIO - Test Runner
+---
+
+Getting Started
+===============
+
+WebdriverIO comes with its own test runner to help you get started with integration testing as quickly as possible. All the fiddling around hooking up WebdriverIO with a test framework belongs to the past. The WebdriverIO runner does all the work for you and helps you to run your tests as efficiently as possible.
+
+To see the command line interface help just type the following command in your terminal:
+
+```txt
+$ ./node_modules/.bin/wdio --help
+
+WebdriverIO CLI runner
+
+Usage: wdio [options] [configFile]
+config file defaults to wdio.conf.js
+The [options] object will override values from the config file.
+
+Options:
+  --help, -h            prints WebdriverIO help menu
+  --version, -v         prints WebdriverIO version
+  --host                Selenium server host address
+  --port                Selenium server port
+  --path                Selenium server path (default: /wd/hub)
+  --user, -u            username if using a cloud service as Selenium backend
+  --key, -k             corresponding access key to the user
+  --watch               watch specs for changes
+  --logLevel, -l        level of logging verbosity (default: silent)
+  --coloredLogs, -c     if true enables colors for log output (default: true)
+  --bail                stop test runner after specific amount of tests have failed (default: 0 - don't bail)
+  --screenshotPath, -s  saves a screenshot to a given path if a command fails
+  --baseUrl, -b         shorten url command calls by setting a base url
+  --waitforTimeout, -w  timeout for all waitForXXX commands (default: 1000ms)
+  --framework, -f       defines the framework (Mocha, Jasmine or Cucumber) to run the specs (default: mocha)
+  --reporters, -r       reporters to print out the results on stdout
+  --suite               overwrites the specs attribute and runs the defined suite
+  --spec                run only a certain spec file
+  --cucumberOpts.*      Cucumber options, see the full list options at https://github.com/webdriverio/wdio-cucumber-framework#cucumberopts-options
+  --jasmineOpts.*       Jasmine options, see the full list options at https://github.com/webdriverio/wdio-jasmine-framework#jasminenodeopts-options
+  --mochaOpts.*         Mocha options, see the full list options at http://mochajs.org
+```
+
+Sweet! Now you need to define a configuration file where all information about your tests, capabilities and settings are set. Switch over to the [Configuration File](/guide/testrunner/configurationfile.html) section to find out how that file should look like. With the `wdio` configuration helper it is super easy to generate your config file. Just run:
+
+```sh
+$ ./node_modules/.bin/wdio config
+```
+
+and it launches the helper utility. It will ask you questions depending on the answers you give. This way
+you can generate your config file in less than a minute.
+
+<div class="cliwindow" style="width: 92%">
+![WDIO configuration utility](/images/config-utility.gif "WDIO configuration utility")
+</div>
+
+Once you have your configuration file set up you can start your
+integration tests by calling:
+
+```sh
+$ ./node_modules/.bin/wdio wdio.conf.js
+```
+
+That's it! Now, you can access to the selenium instance via the global variable `browser`.
+
+## Run the test runner programmatically
+
+Instead of calling the wdio command you can also include the test runner as module and run in within any arbitrary environment. For that you need to require the launcher module (in `/node_modules/webdriverio/build/launcher`) the following way:
+
+```js
+var Launcher = require('webdriverio').Launcher;
+```
+
+After that you create an instance of the launcher and run the test. The Launcher class expects as parameter the url to the config file and accepts [certain](https://github.com/webdriverio/webdriverio/blob/973f23d8949dae8168e96b1b709e5b19241a373b/lib/cli.js#L51-L55) parameters that will overwrite the value in the config.
+
+```js
+var wdio = new Launcher(opts.configFile, opts);
+wdio.run().then(function (code) {
+    process.exit(code);
+}, function (error) {
+    console.error('Launcher failed to start the test', error.stacktrace);
+    process.exit(1);
+});
+```
+
+The run command returns a [Promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) that gets resolved if the test ran successful or failed or gets rejected if the launcher was not able to start run the tests.

static/js/ketcher2/node_modules/webdriverio/docs/guide/testrunner/jenkins.md

@@ -0,0 +1,51 @@
+name: jenkins
+category: testrunner
+tags: guide
+index: 7
+title: WebdriverIO - Test Runner Jenkins Integration
+---
+
+Jenkins Integration
+===================
+
+WebdriverIO offers a tight integration to CI systems like [Jenkins](https://jenkins-ci.org/). With the [junit reporter](https://github.com/webdriverio/wdio-junit-reporter) you can easily debug your tests as well as keep track of your test results. The integration is pretty easy. There is a [demo project](https://github.com/christian-bromann/wdio-demo) we used in this tutorial to demonstrate how to integrate a WebdriverIO testsuite with Jenkins.
+
+First we need to define `junit` as test reporter. Also make sure you have it installed (`$ npm install --save-dev wdio-junit-reporter`) and that we save our xunit results at a place where Jenkins can pick them up. Therefore we define our reporter in our config as follows:
+
+```js
+// wdio.conf.js
+module.exports = {
+    // ...
+    reporters: ['dot', 'junit'],
+    reporterOptions: {
+        junit: {
+            outputDir: './'
+        }
+    },
+    // ...
+};
+```
+
+It is up to you which framework you want to choose. The reports will be similar. This tutorial is going to use Jasmine. After you have written [couple of tests](https://github.com/christian-bromann/wdio-demo/tree/master/test/specs) you can begin to setup a new Jenkins job. Give it a name and a description:
+
+![Name And Description](/images/jenkins-jobname.png "Name And Description")
+
+Then make sure it grabs always the newest version of your repository:
+
+![Jenkins Git Setup](/images/jenkins-gitsetup.png "Jenkins Git Setup")
+
+Now the important part: create a build step to execute shell commands. That build step needs to build your project. Since this demo project only tests an external app we don't need to build anything but install the node dependencies and run our test command `npm test` which is an alias for `node_modules/.bin/wdio test/wdio.conf.js`.
+
+![Build Step](/images/jenkins-runjob.png "Build Step")
+
+After our test we want Jenkins to track our xunit report. To do so we have to add a post-build action called _"Publish JUnit test result report"_. You could also install an external xunit plugin to track your reports. The JUnit one comes with the basic Jenkins installation and is sufficient enough for now.
+
+According to our config file we store the xunit reports in our workspace root directory. These reports are xml files. So all we need to do in order to track the reports is to point Jenkins to all xml files in our root directory:
+
+![Post-build Action](/images/jenkins-postjob.png "Post-build Action")
+
+That's it! This is all you need to setup Jenkins to run your WebdriverIO jobs. The only thing that didn't got mentioned is that Jenkins is setup in a way that it runs Node.js v0.12 and has the [Sauce Labs](https://saucelabs.com/) environment variables set in the settings.
+
+Your job will now provide detailed test results with history charts, stacktrace information on failed jobs as well as a list of commands with payload that got used in each test.
+
+![Jenkins Final Integration](/images/jenkins-final.png "Jenkins Final Integration")

static/js/ketcher2/node_modules/webdriverio/docs/guide/testrunner/organizesuite.md

@@ -0,0 +1,112 @@
+name: organizing suites
+category: testrunner
+tags: guide
+index: 4
+title: WebdriverIO - Organize Test Suite
+---
+
+Organizing Test Suites
+===================
+
+While your project is growing you will inevitably add more and more integration tests. This will increase your build time and will also slow down your productivity. To prevent this you should start to run your tests in parallel. You might have already recognised that WebdriverIO creates for each spec (or feature file in cucumber) a single Selenium session. In general, you should try to test a single feature in your app in one spec file. Try to not have too many or too less tests in one file. However, there is no golden rule about that.
+
+Once you get more and more spec files you should start running them concurrently. To do so you can adjust the [`maxInstances`](https://github.com/webdriverio/webdriverio/blob/master/examples/wdio.conf.js#L52-L60) property in your config file. WebdriverIO allows you to run your tests with maximum concurrency meaning that no matter how many files and tests you have, they could run all in parallel. Though there are certain limits (computer CPU, concurrency restrictions).
+
+> Let's say you have 3 different capabilities (Chrome, Firefox, and Safari) and you have set maxInstances to 1, the wdio test runner will spawn 3 processes. Therefore, if you have 10 spec files and you set maxInstances to 10; all spec files will get tested at the same time and 30 processes will get spawned.
+
+You can define the `maxInstance` property globally to set the attribute for all browser. If you run your own Selenium grid it could be that you have more capacity for one browser than for an other one. In this case you can limit the `maxInstance` in your capability object:
+
+```js
+// wdio.conf.js
+exports.config = {
+    // ...
+    // set maxInstance for all browser
+    maxInstances: 10,
+    // ...
+    capabilities: [{
+        browserName: "firefox"
+    }, {
+        // maxInstances can get overwritten per capability. So if you have an in-house Selenium
+        // grid with only 5 firefox instance available you can make sure that not more than
+        // 5 instance gets started at a time.
+        browserName: 'chrome'
+    }],
+    // ...
+}
+```
+
+## Inherit From Main Config File
+
+If you run your test suite in multiple environments (e.g. dev and integration) it could be helpful to have multiple configuration files to keep them easy manageable. Similar to the [page object concept](/guide/testrunner/pageobjects.html) you first create a main config file. It contains all configurations you share across environments. Then for each environment you can create a file and supplement the information from the main config file with environment specific ones:
+
+```js
+// wdio.dev.config.js
+var merge = require('deepmerge');
+var wdioConf = require('./wdio.conf.js');
+
+// have main config file as default but overwrite environment specific information
+exports.config = merge(wdioConf.config, {
+    capabilities: [
+        // more caps defined here
+        // ...
+    ],
+
+    // run tests on sauce instead locally
+    user: process.env.SAUCE_USERNAME,
+    key: process.env.SAUCE_ACCESS_KEY,
+    services: ['sauce']
+});
+
+// add an additional reporter
+exports.config.reporters.push('allure');
+```
+
+## Group Test Specs
+
+You can easily group test specs in suites and run single specific suites instead of all of them. To do so you first need to define your suites in your wdio config:
+
+```js
+// wdio.conf.js
+exports.config = {
+    // define all tests
+    specs: ['./test/specs/**/*.spec.js'],
+    // ...
+    // define specific suites
+    suites: {
+        login: [
+            './test/specs/login.success.spec.js',
+            './test/specs/login.failure.spec.js'
+        ],
+        otherFeature: [
+            // ...
+        ]
+    },
+    // ...
+}
+```
+
+If you now want to run a single suite only you can pass the suite name as cli argument like
+
+```sh
+$ wdio wdio.conf.js --suite login
+```
+
+or run multiple suites at once
+
+```sh
+$ wdio wdio.conf.js --suite login,otherFeature
+```
+
+## Run Single Test Suites
+
+If you are working on your WebdriverIO tests you don't want to execute your whole suite everytime you added an assertion or any other code. With the `--spec` parameter you can specify which suite (Mocha, Jasmine) or feature (Cucumber) should be run. For example if you only want to run your login test, do:
+
+```sh
+$ wdio wdio.conf.js --spec ./test/specs/e2e/login.js
+```
+
+Note that each test file is running in a single test runner process. Since we don't scan files in advance you _can't_ use for example `describe.only` at the top of your spec file to say Mocha to only run that suite. This feature will help you though to do that in the same way.
+
+## Stop testing after failure
+
+With the `bail` option you can specify when WebdriverIO should stop the test run after test failures. This can be helpful when you have a big test suite and want to avoid long test runs when you already know that your build will break. The option expects a number that specifies after how many spec failures it should stop the whole test run. The default is `0` meaning that it always runs all tests specs it can find.

static/js/ketcher2/node_modules/webdriverio/docs/guide/testrunner/pageobjects.md

@@ -0,0 +1,166 @@
+name: pageobjects
+category: testrunner
+tags: guide
+index: 6
+title: WebdriverIO - Page Object Pattern
+---
+
+Page Object Pattern
+===================
+
+The new version (v4) of WebdriverIO was designed with Page Object Pattern support in mind. By introducing the "elements as first citizen" principle it is now possible to build up large test suites using this pattern. There are no additional packages required to create page objects. It turns out that `Object.create` provides all necessary features we need:
+
+- inheritance between page objects
+- lazy loading of elements and
+- encapsulation of methods and actions
+
+The goal behind page objects is to abstract any page information away from the actual tests. Ideally you should store all selectors or specific instructions that are unique for a certain page in a page object, so that you still can run your test after you've completely redesigned your page.
+
+First off we need a main page object that we call `Page`. It will contain general selectors or methods all page objects will inherit from. Apart from all child page objects `Page` is created using the prototype model:
+
+```js
+function Page () {
+    this.title = 'My Page';
+}
+
+Page.prototype.open = function (path) {
+    browser.url('/' + path)
+}
+
+module.exports = new Page()
+```
+Or, using ES6 class:
+```js
+"use strict";
+
+class Page {
+
+	constructor() {
+		this.title = 'My Page';
+	}
+
+	open(path) {
+		browser.url('/' + path);
+	}
+
+}
+module.exports = new Page();
+```
+
+We will always export an instance of a page object and never create that instance in the test. Since we are writing end to end tests we always see the page as a stateless construct the same way as each http request is a stateless construct. Sure, the browser can carry session information and therefore can display different pages based on different sessions, but this shouldn't be reflected within a page object. These state changes should emerge from your actual tests.
+
+Let's start testing the first page. For demo purposes we use [The Internet](http://the-internet.herokuapp.com) website by [Elemental Selenium](http://elementalselenium.com/) as guinea pig. Let's try to build a page object example for the [login page](http://the-internet.herokuapp.com/login). First step is to write all important selectors that are required in our `login.page` object as getter functions. As mentioned above we are using the `Object.create` method to inherit the prototype of our main page:
+
+```js
+// login.page.js
+var Page = require('./page')
+
+var LoginPage = Object.create(Page, {
+    /**
+     * define elements
+     */
+    username: { get: function () { return browser.element('#username'); } },
+    password: { get: function () { return browser.element('#password'); } },
+    form:     { get: function () { return browser.element('#login'); } },
+    flash:    { get: function () { return browser.element('#flash'); } },
+
+    /**
+     * define or overwrite page methods
+     */
+    open: { value: function() {
+        Page.open.call(this, 'login');
+    } },
+
+    submit: { value: function() {
+        this.form.submitForm();
+    } }
+});
+
+module.exports = LoginPage;
+```
+OR, when using ES6 class:
+
+```js
+// login.page.js
+"use strict";
+
+var Page = require('./page')
+
+class LoginPage extends Page {
+
+    get username()  { return browser.element('#username'); }
+    get password()  { return browser.element('#password'); }
+    get form()      { return browser.element('#login'); }
+    get flash()     { return browser.element('#flash'); }
+    
+    open() {
+        super.open('login');
+    }
+    
+    submit() {
+        this.form.submitForm();
+    }
+    
+}
+module.exports = new LoginPage();
+```
+Defining selectors in getter functions might look a bit verbose but it is really useful. These functions get evaluated when you actually access the property and not when you generate the object. With that you always request the element before you do an action on it.
+
+WebdriverIO internally remembers the last result of a command. If you chain an element command with an action command it finds the element from the previous command and uses the result to execute the action. With that you can remove the selector (first parameter) and the command looks as simple as:
+
+```js
+LoginPage.username.setValue('Max Mustermann');
+```
+
+which is basically the same thing as:
+
+```js
+var elem = browser.element('#username');
+elem.setValue('Max Mustermann');
+```
+
+or
+
+```js
+browser.element('#username').setValue('Max Mustermann');
+```
+
+or
+
+```js
+browser.setValue('#username', 'Max Mustermann');
+```
+
+After we've defined all required elements and methods for the page we can start to write the test for it. All we need to do to use the page object is to require it and that's it. The `Object.create` method returns an instance of that page so we can start using it right away. By adding an additional assertion framework you can make your tests even more expressive:
+
+```js
+// login.spec.js
+var expect = require('chai').expect;
+var LoginPage = require('../pageobjects/login.page');
+
+describe('login form', function () {
+    it('should deny access with wrong creds', function () {
+        LoginPage.open();
+        LoginPage.username.setValue('foo');
+        LoginPage.password.setValue('bar');
+        LoginPage.submit();
+
+        expect(LoginPage.flash.getText()).to.contain('Your username is invalid!');
+    });
+
+    it('should allow access with correct creds', function () {
+        LoginPage.open();
+        LoginPage.username.setValue('tomsmith');
+        LoginPage.password.setValue('SuperSecretPassword!');
+        LoginPage.submit();
+
+        expect(LoginPage.flash.getText()).to.contain('You logged into a secure area!');
+    });
+});
+```
+
+From the structural side it makes sense to separate spec files and page objects and put them into different directories. Additionally you can give each page object the ending: `.page.js`. This way it is easy to figure out that you actually require a page object if you execute `var LoginPage = require('../pageobjects/form.page');`.
+
+This is the basic principle of how to write page objects with WebdriverIO. Note that you can build up way more complex page object structures than this. For example have specific page objects for modals or split up a huge page object into different sections objects that inherit from the main page object. The pattern gives you really a lot of opportunities to encapsulate page information from your actual tests, which is important to keep your test suite structured and clear in times where the project and number of tests grows.
+
+You can find this and some more page object examples in the [example folder](https://github.com/webdriverio/webdriverio/tree/master/examples/pageobject) on GitHub.

static/js/ketcher2/node_modules/webdriverio/docs/guide/testrunner/retry.md

@@ -0,0 +1,82 @@
+name: Retry Flaky Tests
+category: testrunner
+tags: guide
+index: 9
+title: WebdriverIO - Retry Flaky Tests
+---
+
+Retry Flaky Tests
+=================
+
+You can rerun certain tests with the WebdriverIO testrunner that turn out to be unstable due to e.g. flaky network or race conditions. However it is not recommended to just increase the rerun rate if tests become unstable.
+
+## Rerun suites in MochaJS
+
+Since version 3 of MochaJS you can rerun whole test suites (everything inside an `describe` block). If you use Mocha you should favor this retry mechanism instead of the WebdriverIO implementation that only allows you to rerun certain test blocks (everything within an `it` block). Here is an example how to rerun a whole suite in MochaJS:
+
+```js
+describe('retries', function() {
+    // Retry all tests in this suite up to 4 times
+    this.retries(4);
+
+    beforeEach(function () {
+        browser.url('http://www.yahoo.com');
+    });
+
+    it('should succeed on the 3rd try', function () {
+        // Specify this test to only retry up to 2 times
+        this.retries(2);
+        console.log('run');
+        expect(browser.isVisible('.foo')).to.eventually.be.true;
+    });
+});
+```
+
+## Rerun single tests in Jasmine or Mocha
+
+To rerun a certain test block just apply the number of reruns as last parameter after the test block function:
+
+```js
+describe('my flaky app', function () {
+    /**
+     * spec that runs max 4 times (1 actual run + 3 reruns)
+     */
+    it('should rerun a test at least 3 times', function () {
+        // ...
+    }, 3);
+});
+```
+
+The same works for hooks too:
+
+```js
+describe('my flaky app', function () {
+    /**
+     * hook that runs max 2 times (1 actual run + 1 rerun)
+     */
+    beforeEach(function () {
+        // ...
+    }, 1)
+
+    // ...
+});
+```
+
+It is __not__ possible to rerun whole suites, only hooks or test blocks. To use this you have to have the [wdio-mocha-framework](https://github.com/webdriverio/wdio-mocha-framework) adapter installed with `v0.3.0` or greater or the [wdio-jasmine-framework](https://github.com/webdriverio/wdio-jasmine-framework) adapter with `v0.2.0` or greater.
+
+## Rerun Step Definitions in Cucumber
+
+To define a rerun rate for a certain step definitions just apply a retry option to it, like:
+
+```js
+module.exports = function () {
+    /**
+     * step definition that runs max 3 times (1 actual run + 2 reruns)
+     */
+    this.Given(/^some step definition$/, { retry: 2 }, () => {
+        // ...
+    })
+    // ...
+```
+
+Reruns can only be defined in your step definitions file and not in your feature file. To use this you have to have the [wdio-cucumber-framework](https://github.com/webdriverio/wdio-cucumber-framework) adapter installed with `v0.1.0` or greater.

static/js/ketcher2/node_modules/webdriverio/docs/guide/testrunner/timeouts.md

@@ -0,0 +1,133 @@
+name: Timeouts
+category: testrunner
+tags: guide
+index: 5
+title: WebdriverIO - Timeouts
+---
+
+Timeouts
+========
+
+Each command in WebdriverIO is an asynchronous operation where a request is fired to the Selenium server (or a cloud service like [Sauce Labs](https://saucelabs.com/)), and its response contains the result once the action has completed or failed. Therefore time is a crucial component in the whole testing process. When a certain action depends on the state of a different action, you need to make sure that they get executed in the right order. Timeouts play an important role when dealing with these issues.
+
+## Selenium timeouts
+
+### Session Script Timeout
+
+A session has an associated session script timeout that specifies a time to wait for asynchronous scripts to run. Unless stated otherwise it is 30 seconds. You can set this timeout via:
+
+```js
+browser.timeouts('script', 60000);
+browser.executeAsync(function (done) {
+    console.log('this should not fail');
+    setTimeout(done, 59000);
+});
+```
+
+### Session Page Load Timeout
+
+A session has an associated session page load timeout that specifies a time to wait for the page loading to complete. Unless stated otherwise it is 300,000 milliseconds. You can set this timeout via:
+
+```js
+browser.timeouts('pageLoad', 10000);
+```
+
+> The `pageLoad` keyword is a part of the official WebDriver [specification](https://www.w3.org/TR/webdriver/#set-timeouts), but might not be [supported](https://github.com/seleniumhq/selenium-google-code-issue-archive/issues/687) for your browser (the previous name is `page load`).
+
+### Session Implicit Wait Timeout
+
+A session has an associated session implicit wait timeout that specifies a time to wait for the implicit element location strategy when locating elements using the [`element`](/api/protocol/element.html) or [`elements`](/api/protocol/elements.html) commands. Unless stated otherwise it is zero milliseconds. You can set this timeout via:
+
+```js
+browser.timeouts('implicit', 5000);
+```
+
+## WebdriverIO related timeouts
+
+### WaitForXXX timeout
+
+WebdriverIO provides multiple commands to wait on elements to reach a certain state (e.g. enabled, visible, existing). These commands take a selector argument and a timeout number which declares how long the instance should wait for that element to reach the state. The `waitforTimeout` option allows you to set the global timeout for all waitFor commands so you don't need to set the same timeout over and over again. Note the lowercase `f`.
+
+```js
+// wdio.conf.js
+exports.config = {
+    // ...
+    waitforTimeout: 5000,
+    // ...
+};
+```
+
+In your test you now can do this:
+
+```js
+var myElem = browser.element('#myElem');
+myElem.waitForVisible();
+
+// which is the same as
+browser.waitForVisible('#myElem');
+
+// which is the same as
+browser.waitForVisible('#myElem', 5000);
+```
+
+## Framework related timeouts
+
+Also the testing framework you use with WebdriverIO has to deal with timeouts especially since everything is asynchronous. It ensures that the test process don't get stuck if something went wrong. By default the timeout is set to 10 seconds which means that a single test should not take longer than that. A single test in Mocha looks like:
+
+```js
+it('should login into the application', function () {
+    browser.url('/login');
+
+    var form = browser.element('form');
+    var username = browser.element('#username');
+    var password = browser.element('#password');
+
+    username.setValue('userXY');
+    password.setValue('******');
+    form.submit();
+
+    expect(browser.getTitle()).to.be.equal('Admin Area');
+});
+```
+
+In Cucumber the timeout applies to a single step definition. However if you want to increase the timeout because your test takes longer than the default value you need to set it in the framework options. This is for Mocha:
+
+```js
+// wdio.conf.js
+exports.config = {
+    // ...
+    framework: 'mocha',
+    mochaOpts: {
+        timeout: 20000
+    },
+    // ...
+}
+```
+
+For Jasmine:
+
+```js
+// wdio.conf.js
+exports.config = {
+    // ...
+    framework: 'jasmine',
+    jasmineNodeOpts: {
+        defaultTimeoutInterval: 20000
+    },
+    // ...
+}
+```
+
+and for Cucumber:
+
+```js
+// wdio.conf.js
+exports.config = {
+    // ...
+    framework: 'cucumber',
+    cucumberOpts: {
+        timeout: 20000
+    },
+    // ...
+}
+```

static/js/ketcher2/node_modules/webdriverio/docs/guide/usage/autocompletion.md

@@ -0,0 +1,54 @@
+name: autocompletion
+category: usage
+tags: guide
+index: 8
+title: WebdriverIO - Autocompletion
+---
+
+Autocompletion
+=====================
+
+If you have been writing program code for a while, you probably like autocompletion.
+Autocomplete is available out of the box in many code editors. However if autocompletion is required for packages that are not installed in the usual locations or are excluded from indexing for some reasons, these too could be added via configuration changes.
+
+
+![Autocompletion](/images/autocompletion/0.png)
+
+[JSDoc](http://usejsdoc.org/) is used for documenting code. It helps to see more additional details about parameters and their types.
+
+![Autocompletion](/images/autocompletion/1.png)
+
+Use standard shortcuts *⇧ + ⌥ + SPACE* on IntelliJ Platform to see available documentation:
+
+![Autocompletion](/images/autocompletion/2.png)
+
+So, let's start to consider an example of adding autocompletion to code editors on the IntelliJ Platform like WebStorm.
+
+### Node.js Core modules as External library
+
+Open *Settings -> Preferences -> Languages & Frameworks -> JavaScript -> Libraries*
+
+![Autocompletion](/images/autocompletion/3.png)
+
+Add new library
+
+![Autocompletion](/images/autocompletion/4.png)
+
+Add directory with WebdriverIO commands
+
+![Autocompletion](/images/autocompletion/5.png)
+![Autocompletion](/images/autocompletion/6.png)
+![Autocompletion](/images/autocompletion/7.png)
+
+Enter documentation URL
+
+![Autocompletion](/images/autocompletion/8.png)
+![Autocompletion](/images/autocompletion/9.png)
+![Autocompletion](/images/autocompletion/10.png)
+
+### Using TypeScript community stubs (TypeScript definition files)
+
+WebStorm provides one more workaround for adding coding assistance. It allows you to download [DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped) stubs.
+
+![Autocompletion](/images/autocompletion/11.png)
+![Autocompletion](/images/autocompletion/12.png)

static/js/ketcher2/node_modules/webdriverio/docs/guide/usage/bindingscommands.md

@@ -0,0 +1,94 @@
+name: bindingscommands
+category: usage
+tags: guide
+index: 2
+title: WebdriverIO - Bindings & Commands
+---
+
+Bindings & Commands
+=====================
+
+WebdriverIO differentiates between two different method types: protocol bindings and commands. Protocol bindings are the exact representation of the JSONWire protocol interface. They expect the same parameters as described in the [protocol docs](https://github.com/SeleniumHQ/selenium/wiki/JsonWireProtocol).
+
+```js
+console.log(browser.url());
+ /**
+  * returns:
+  *
+  * { state: null,
+  *   sessionId: '684cb251-f0bd-4910-a43d-f3413206e652',
+  *   hCode: 2611472,
+  *   value: 'http://webdriver.io',
+  *   class: 'org.openqa.selenium.remote.Response',
+  *   status: 0 } }
+  *
+  */
+});
+```
+
+WebdriverIO supports all JSONWire protocol bindings (including the new ones from the Webdriver spec) implemented and even a whole bunch of [Appium](http://appium.io/) specific ones for mobile testing.
+
+All other methods like `getValue` or `dragAndDrop` using these commands to provide handy functions who simplify your tests to look more concise and expressive. So instead of doing this:
+
+```js
+var element = browser.element('#myElem');
+var res = browser.elementIdCssProperty(element.value.ELEMENT, 'width');
+assert(res.value === '100px');
+});
+```
+
+you can simply do this:
+
+```js
+var width = browser.getCssProperty('#myElem', 'width')
+assert(width.parsed.value === 100);
+/**
+ * console.log(width) returns:
+ *
+ * { property: 'width',
+ *   value: '100px',
+ *   parsed: { type: 'number', string: '100px', unit: 'px', value: 100 } }
+ */
+});
+```
+
+It not only shortens your code it also makes the return value testable. You don't have to worry about how to combine the JSONWire bindings to achieve a certain action, just use the command methods.
+
+When you call a command WebdriverIO automatically tries to propagate the prototype to the result. This of course only works if the result prototype can be modified (e.g. for objects). This allows the developer to chain commands like this:
+
+```js
+browser.click('#elem1').click('#elem2');
+```
+
+It also enables the ability to call commands on element results. The browser instance remembers the last result of each command and can propagate it as a parameter for the next command. This way you can call commands directly on element results:
+
+```html
+<div id="elem1" onClick="document.getElementById('elem1').innerHTML = 'some new text'">some text</div>
+```
+
+```js
+var element = browser.element('#elem1');
+console.log(element.getText()); // outputs: "some text"
+element.click();
+console.log(element.getText()); // outputs: "some new text"
+```
+
+With this method you can seamlessly encapsulate your page information into a [page object](http://webdriver.io/guide/testrunner/pageobjects.html) which will allow you to write highly expressive tests like:
+
+```js
+var expect = require('chai').expect;
+var FormPage = require('../pageobjects/form.page');
+
+describe('auth form', function () {
+    it('should deny access with wrong creds', function () {
+        FormPage.open();
+        FormPage.username.setValue('foo');
+        FormPage.password.setValue('bar');
+        FormPage.submit();
+
+        expect(FormPage.flash.getText()).to.contain('Your username is invalid!');
+    });
+});
+```
+
+Check out the documentation page on [page objects](http://webdriver.io/guide/testrunner/pageobjects.html) or have a look on our [examples](https://github.com/webdriverio/webdriverio/tree/master/examples/pageobject)

static/js/ketcher2/node_modules/webdriverio/docs/guide/usage/cloudservices.md

@@ -0,0 +1,128 @@
+name: cloudservices
+category: usage
+tags: guide
+index: 2
+title: WebdriverIO - Using Cloud Services
+---
+
+# Using Cloud Services
+
+Using ondemand services like Sauce Labs, Browserstack or TestingBot with WebdriverIO is pretty simple.
+
+1. Make sure WebdriverIO uses their host (e.g. `ondemand.saucelabs.com` for Sauce Labs) as the selenium server, either by setting the `host` config or letting WebdriverIO configure that automatically based on the value of `user` and `key`.
+2. (optional) Set service specific values for each browser in `desiredCapabilities` (e.g. `build` to specify the build number and cluster multiple tests together).
+3. (optional) Tunnel local traffic to provider, so that your tests can access `localhost`.
+
+If you only want to run cloud services in Travis, you can use the `CI` environment variable to check if you are in Travis and modify the config accordingly.
+
+```javascript
+// wdio.conf.js
+
+var config = {...}
+if (process.env.CI) {
+    config.user = process.env.SAUCE_USERNAME;
+    config.key = process.env.SAUCE_ACCESS_KEY;
+}
+exports.config = config
+```
+
+## [Sauce Labs](https://saucelabs.com/)
+
+It is easy to set up your tests to run remotely in Sauce Labs.
+
+The only requirement is to set the `user` and `key` in your config (either exported by `wdio.conf.js` or passed into `webdriverio.remote(...)`) to your Sauce Labs username and access key.
+
+You can also pass in any optional [test configuration option](https://docs.saucelabs.com/reference/test-configuration/#webdriver-api) as a key/value in the capabilities for any browser.
+
+### [Sauce Connect](https://wiki.saucelabs.com/display/DOCS/Sauce+Connect+Proxy)
+
+If you want to run tests against a server that is not accessible to the Internet (like on `localhost`), then you need to use Sauce Connect.
+
+It is out of the scope of WebdriverIO to support this, so you must start it by yourself.
+
+If you are using the WDIO testrunner download and configure the [`wdio-sauce-service`](https://github.com/webdriverio/wdio-sauce-service) in your `wdio.conf.js`. It helps getting Sauce Connect running and comes with additional features that better integrate your tests into the Sauce service.
+
+### With Travis CI
+
+Travis CI, however, does [have support](http://docs.travis-ci.com/user/sauce-connect/#Setting-up-Sauce-Connect) for starting Sauce Connect before each test, so follow their directions for that if you are interested.
+
+If you do so, you must set the `tunnel-identifier` test configuration option in each browser's capabilities. Travis sets this to the `TRAVIS_JOB_NUMBER` environmental variable by default.
+
+Also if you want to have Sauce Labs group your tests by build number, you can set the `build` to `TRAVIS_BUILD_NUMBER`.
+
+Lastly if you set the `name`, this changes the name of this test in Sauce Labs for this build. If you are using the WDIO testrunner combined with the [`wdio-sauce-service`](https://github.com/webdriverio/wdio-sauce-service) WebdriverIO automatically sets a proper name for the test.
+
+Example `desiredCapabilities`:
+
+```javascript
+browserName: 'chrome',
+version: '27.0',
+platform: 'XP',
+'tunnel-identifier': process.env.TRAVIS_JOB_NUMBER,
+name: 'integration',
+build: process.env.TRAVIS_BUILD_NUMBER
+```
+
+### Timeouts
+
+Since you are running your tests remotely, it might be necessary to increase some timeouts.
+
+You can change the [idle timeout](https://docs.saucelabs.com/reference/test-configuration/#idle-test-timeout) by passing `idle-timeout` as a test configuration option. This controls how long Sauce will wait between commands before closing the connection.
+
+## [BrowserStack](https://www.browserstack.com/)
+
+Browserstack is also supported easily.
+
+The only requirement is to set the `user` and `key` in your config (either exported by `wdio.conf.js` or passed into `webdriverio.remote(...)`) to your Browserstack automate username and access key.
+
+You can also pass in any optional [supported capabilities](https://www.browserstack.com/automate/capabilities) as a key/value in the capabilities for any browser. If you set `browserstack.debug` to `true` it will record a screencast of the session, which might be helpful.
+
+### [Local Testing](https://www.browserstack.com/local-testing#command-line)
+
+If you want to run tests against a server that is not accessible to the Internet (like on `localhost`), then you need to use Local Testing.
+
+It is out of the scope of WebdriverIO to support this, so you must start it by yourself.
+
+If you do use local, you should set `browserstack.local` to `true` in your capabilities.
+
+If you are using the WDIO testrunner download and configure the [`wdio-browserstack-service`](https://github.com/itszero/wdio-browserstack-service) in your `wdio.conf.js`. It helps getting BrowserStack running and comes with additional features that better integrate your tests into the BrowserStack service.
+
+### With Travis CI
+
+If you want to add Local Testing in Travis you have to start it by yourself.
+
+The following script will download and start it in the background. You should run this in Travis before starting the tests.
+
+```bash
+wget https://www.browserstack.com/browserstack-local/BrowserStackLocal-linux-x64.zip
+unzip BrowserStackLocal-linux-x64.zip
+./BrowserStackLocal -v -onlyAutomate -forcelocal $BROWSERSTACK_ACCESS_KEY &
+sleep 3
+```
+
+Also, you might wanna set the `build` to the Travis build number.
+
+Example `desiredCapabilities`:
+
+```javascript
+browserName: 'chrome',
+project: 'myApp',
+version: '44.0',
+build: 'myApp #' + process.env.TRAVIS_BUILD_NUMBER + '.' + process.env.TRAVIS_JOB_NUMBER,
+'browserstack.local': 'true',
+'browserstack.debug': 'true'
+```
+
+## [TestingBot](https://testingbot.com/)
+
+The only requirement is to set the `user` and `key` in your config (either exported by `wdio.conf.js` or passed into `webdriverio.remote(...)`) to your TestingBot username and secret key.
+
+You can also pass in any optional [supported capabilities](https://testingbot.com/support/other/test-options) as a key/value in the capabilities for any browser.
+
+### [Local Testing](https://testingbot.com/support/other/tunnel)
+
+If you want to run tests against a server that is not accessible to the Internet (like on `localhost`), then you need to use Local Testing. TestingBot provides a JAVA based tunnel to allow you to test websites not accessible from the internet.
+
+Their tunnel support page contains the information necessary to get this up and running.
+
+If you are using the WDIO testrunner download and configure the [`wdio-testingbot-service`](https://github.com/testingbot/wdio-testingbot-service) in your `wdio.conf.js`. It helps getting TestingBot running and comes with additional features that better integrate your tests into the TestingBot service.

static/js/ketcher2/node_modules/webdriverio/docs/guide/usage/customcommands.md

@@ -0,0 +1,69 @@
+name: customcommands
+category: usage
+tags: guide
+index: 1
+title: WebdriverIO - Custom Commands
+---
+
+Custom Commands
+===============
+
+If you want to extend the browser instance with your own set of commands there is a method called `addCommand` available from the browser object. You can write your command in a synchronous (default) way the same way as in your specs or asynchronous (like when using WebdriverIO in standalone mode). The following example shows how to add a new command that returns the current url and title as one result only using synchronous commands:
+
+```js
+browser.addCommand("getUrlAndTitle", function (customVar) {
+    return {
+        url: this.getUrl(),
+        title: this.getTitle(),
+        customVar: customVar
+    };
+});
+```
+
+Custom commands give you the opportunity to bundle a specific sequence of commands that are used frequently in a handy single command call. You can define custom commands at any point in your test suite, just make sure that the command is defined before you first use it (the before hook in your wdio.conf.js might be a good point to create them). Also to note: custom commands, like all WebdriverIO commmands, can only be called inside a test hook or it block. In your spec file you can use them like this:
+
+```js
+it('should use my custom command', function () {
+    browser.url('http://www.github.com');
+    var result = browser.getUrlAndTitle('foobar');
+
+    assert.strictEqual(result.url, 'https://github.com/');
+    assert.strictEqual(result.title, 'GitHub · Where software is built');
+    assert.strictEqual(result.customVar, 'foobar');
+});
+```
+
+As mentioned earlier, you can define your command using good old promise syntax. This makes sense if you work with an additional 3rd party library that supports promises or if you want to execute both commands at the same time. Here is the async example, note that the custom command callback has a function name called `async`:
+
+```js
+client.addCommand("getUrlAndTitle", function async () {
+    return Promise.all([
+        this.getUrl(),
+        this.getTitle()
+    ]);
+});
+```
+
+## Integrate 3rd party libraries
+
+If you use external libraries (e.g. to do database calls) that support promises, a nice approach to easily integrate them is to wrap certain API methods within a custom command:
+
+```js
+browser.addCommand('doExternalJob', function async (params) {
+    return externalLib.command(params);
+});
+```
+
+Then just use it in your wdio test specs synchronously:
+
+```js
+it('execute external library in a sync way', function() {
+    browser.url('...');
+    browser.doExternalJob('someParam');
+    console.log(browser.getTitle()); // returns some title
+});
+```
+
+Note that the result of your custom command will be the result of the promise you return. Also there is no support for synchronous commands in standalone mode therefore you always have to handle asynchronous commands using Promises.
+
+By default WebdriverIO will throw an error if you try to overwrite an existing command. You can bypass this behavior by passing `true` as 3rd parameter to the `addCommand` function.

static/js/ketcher2/node_modules/webdriverio/docs/guide/usage/eventhandling.md

@@ -0,0 +1,55 @@
+name: eventhandling
+category: usage
+tags: guide
+index: 6
+title: WebdriverIO - Eventhandling
+---
+
+Eventhandling
+=============
+
+The following functions are supported: `on`,`once`,`emit`,`removeListener`,`removeAllListeners`.
+They behave exactly as described in the official NodeJS [docs](http://nodejs.org/api/events.html).
+There are some predefined events (`error`,`init`,`end`, `command`, `log`) which cover important
+WebdriverIO events.
+
+## Examples
+
+```js
+browser.on('error', function(e) {
+    // will be executed everytime an error occurred
+    // e.g. when element couldn't be found
+    console.log(e.body.value.class);   // -> "org.openqa.selenium.NoSuchElementException"
+    console.log(e.body.value.message); // -> "no such element ..."
+})
+```
+
+Use the `log()` event to log arbitrary data, which can then be logged or displayed by a reporter:
+
+```js
+browser
+    .init()
+    .emit('log', 'Before my method')
+    .click('h2.subheading a')
+    .emit('log', 'After my method', {more: 'data'})
+    .end();
+```
+
+All commands are chainable, so you can use them while chaining your commands
+
+```js
+var cnt;
+
+browser
+    .init()
+    .once('countme', function(e) {
+        console.log(e.elements.length, 'elements were found');
+    })
+    .elements('.myElem').then(function(res) {
+        cnt = res.value;
+    })
+    .emit('countme', cnt)
+    .end();
+```
+
+Note that you can't execute any WebdriverIO commands or any other async operation within the listener function. Event handling comes handy when you want to log certain information but is not considered to be used to do action on certain events like taking a screenshot if an error happens. For use the `onError` hook in your wdio test runner configuration file.

static/js/ketcher2/node_modules/webdriverio/docs/guide/usage/multiremote.md

@@ -0,0 +1,121 @@
+name: multiremote
+category: usage
+tags: guide
+index: 4
+title: WebdriverIO - Multiremote
+---
+
+Run multiple browser at the same time
+=====================================
+
+WebdriverIO allows you to run multiple Selenium sessions in a single test. This becomes handy when you need to test application features where multiple users are required (e.g. chat or WebRTC applications). Instead of creating a couple of remote instances where you need to execute common commands like [init](http://webdriver.io/api/protocol/init.html) or [url](http://webdriver.io/api/protocol/url.html) on each of those instances, you can simply create a multiremote instance and control all browser at the same time. To do so just use the `multiremote` function and pass an object with named browser with their capabilities into it. By giving each capability a name you will be able to easy select and access that single instance when executing commands on a single instance. Here is an example demonstrating a how to create a multiremote WebdriverIO instance in standalone mode:
+
+```js
+var webdriverio = require('webdriverio');
+var browser = webdriverio.multiremote({
+    myChromeBrowser: {
+        desiredCapabilities: {
+            browserName: 'chrome'
+        }
+    },
+    myFirefoxBrowser: {
+        desiredCapabilities: {
+            browserName: 'firefox'
+        }
+    }
+});
+```
+
+This would create two Selenium sessions with Chrome and Firefox. Instead of just Chrome and Firefox you can also boot up two mobile devices using [Appium](http://appium.io/). Any kind of OS/browser combination is possible here. All commands you call with the `browser` variable gets executed in parallel with each instance. This helps to streamline your integration test and speedup the execution a bit. For example initialise the session and open up an url:
+
+```js
+browser.init().url('http://chat.socket.io/');
+```
+
+Using the multiremote instance changes the way how results are accessible in callback functions. Since more than one browser executes the command we also receive more than one result.
+
+```js
+browser
+    .init()
+    .url('https://www.whatismybrowser.com/')
+    .getText('.string-major').then(function(result) {
+        console.log(result.resultChrome); // returns: 'Chrome 40 on Mac OS X (Yosemite)'
+        console.log(result.resultFirefox); // returns: 'Firefox 35 on Mac OS X (Yosemite)'
+    })
+    .end();
+```
+
+You will notice that each command gets executed one by one. That means that the command finishes once all browser have executed it. This is helpful because it keeps the browser actions synced and it makes it easier to understand what currently happens.
+
+Sometimes it is necessary to do different things with each browser in order to test something. For instance if we want to test a chat application, there has to be one browser who inputs a text message while the other browser waits to receive that message and do an assertion on it. You can get access to a single instance by using the `select` method.
+
+```js
+var myChromeBrowser = browser.select('myChromeBrowser');
+var myFirefoxBrowser = browser.select('myFirefoxBrowser');
+ 
+myChromeBrowser
+    .setValue('#message', 'Hi, I am Chrome')
+    .click('#send');
+ 
+myFirefoxBrowser
+    .waitForExist('.messages', 5000)
+    .getText('.messages').then(function(messages) {
+        assert.equal(messages, 'Hi, I am Chrome');
+    });
+```
+
+In that example the `myFirefoxBrowser` instance will start waiting on a messages once the `myChromeBrowser` instance clicked on the send button. The execution is in parallel. Multiremote makes it easy and convenient to control multiple browser either doing the same thing in parallel or something different. In the latter case it might be the case where you want to sync up your instances to do something in parallel again. To do so just call the `sync` method. All methods which are chained behind the `sync` method get executed in parallel again:
+
+```js
+// these commands get executed in parallel by all defined instances
+browser.init().url('http://example.com');
+ 
+// do something with the Chrome browser
+myChromeBrowser.setValue('.chatMessage', 'Hey Whats up!').keys('Enter')
+ 
+// do something with the Firefox browser
+myFirefoxBrowser.getText('.message').then(function (message) {
+    console.log(messages);
+    // returns: "Hey Whats up!"
+});
+ 
+// now sync instances again
+browser.sync().url('http://anotherwebsite.com');
+```
+
+All these examples demonstrate the usage of multiremote in standalone mode. You can of course also use it with the wdio test runner. To do so just define the `capabilities` object in your `wdio.conf.js` as an object with the browser names as keys:
+
+```js
+export.config = {
+    // ...
+    capabilities: {
+        myChromeBrowser: {
+            desiredCapabilities: {
+                browserName: 'chrome'
+            }
+        },
+        myFirefoxBrowser: {
+            desiredCapabilities: {
+                browserName: 'firefox'
+            }
+        }        
+    }
+    // ...
+};
+```
+
+Since all commands are running synchronous with the wdio test runner, all multiremote commands are synchronous as well. That means that the previous described `sync` method got obsolete. In your test specs each single browser is globally available by its browser name:
+
+```js
+it('should do something with two browser', function () {
+    browser.url('http://google.com');
+    console.log(browser.getTitle()); // returns {myChromeBrowser: 'Google', myFirefoxBrowser: 'Google'}
+ 
+    myFirefoxBrowser.url('http://yahoo.com');
+    console.log(myFirefoxBrowser.getTitle()); // return 'Yahoo'
+ 
+    console.log(browser.getTitle()); // returns {myChromeBrowser: 'Google', myFirefoxBrowser: 'Yahoo'}
+});
+```
+
+__Note:__ Multiremote is not meant to execute all your tests in parallel. It should help you to coordinate more than one browser for sophisticated integration tests.

static/js/ketcher2/node_modules/webdriverio/docs/guide/usage/repl.md

@@ -0,0 +1,27 @@
+name: repl
+category: usage
+tags: guide
+index: 9
+title: WebdriverIO - REPL interface
+---
+
+REPL interface
+==============
+
+With `v4.5.0` WebdriverIO introduces a [REPL](https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop) interface that helps you to not only discover the framework API but also debug and inspect your tests. It can be used in multiple ways. First you can use it as CLI command and spawn a Selenium session from the command line, e.g.
+
+```sh
+$ wdio repl chrome
+```
+
+This would open a Chrome browser that you can control with the REPL interface. Make sure you have a Selenium server running on port `4444` in order to initiate the session. If you have a [SauceLabs](https://saucelabs.com) (or other cloud vendor) account you can also directly run the browser on your command line in the cloud via:
+
+```sh
+$ wdio repl chrome -u $SAUCE_USERNAME -k $SAUCE_ACCESS_KEY
+```
+
+You can apply any options (see `wdio --help`) available for your REPL session. It is recommended to install the [`wdio-sync`](https://github.com/webdriverio/wdio-sync) (if not already installed with the framework adapter) package when using the REPL as it allows you to use some advanced features (e.g. like the `$` and `$$` functions).
+
+![WebdriverIO REPL](http://webdriver.io/images/repl.gif)
+
+Another way to use the REPL is in between your tests via the [`debug`](/api/utility/debug.html) command. It will stop the browser when executed and enables you to jump into the application (e.g. to the dev tools) or control the browser from the command line. This is helpful when some commands don't trigger a certain action as expected. With the REPL you can then try out the commands to see which are working most reliable.

static/js/ketcher2/node_modules/webdriverio/docs/guide/usage/selectors.md

@@ -0,0 +1,177 @@
+name: selectors
+category: usage
+tags: guide
+index: 0
+title: WebdriverIO - Selectors
+---
+
+Selectors
+=========
+
+The JsonWireProtocol provides several strategies to query an element. WebdriverIO simplifies these to make it more familiar with the common existing selector libraries like [Sizzle](http://sizzlejs.com/). The following selector types are supported:
+
+## CSS Query Selector
+
+```js
+browser.click('h2.subheading a');
+```
+
+## Link Text
+
+To get an anchor element with a specific text in it, query the text starting with an equal (=) sign.
+For example:
+
+```html
+<a href="http://webdriver.io">WebdriverIO</a>
+```
+
+```js
+console.log(browser.getText('=WebdriverIO')); // outputs: "WebdriverIO"
+console.log(browser.getAttribute('=WebdriverIO', 'href')); // outputs: "http://webdriver.io"
+```
+
+## Partial Link Text
+
+To find a anchor element whose visible text partially matches your search value, query it by using `*=`
+in front of the query string (e.g. `*=driver`)
+
+```html
+<a href="http://webdriver.io">WebdriverIO</a>
+```
+
+```js
+console.log(browser.getText('*=driver')); // outputs: "WebdriverIO"
+```
+
+## Element with certain text
+
+The same technique can be applied to elements as well, e.g. query a level 1 heading with the text "Welcome to my Page":
+
+```html
+<h1>Welcome to my Page</h1>
+```
+
+```js
+console.log(browser.getText('h1=Welcome to my Page')); // outputs: "Welcome to my Page"
+console.log(browser.getTagName('h1=Welcome to my Page')); // outputs: "h1"
+```
+
+or using query partial text
+
+```js
+console.log(browser.getText('h1*=Welcome')); // outputs: "Welcome to my Page"
+```
+
+The same works for ids and class names:
+
+```html
+<i class="someElem" id="elem">WebdriverIO is the best</i>
+```
+```js
+console.log(browser.getText('.someElem=WebdriverIO is the best')); // outputs: "WebdriverIO is the best"
+console.log(browser.getText('#elem=WebdriverIO is the best')); // outputs: "WebdriverIO is the best"
+console.log(browser.getText('.someElem*=WebdriverIO')); // outputs: "WebdriverIO is the best"
+console.log(browser.getText('#elem*=WebdriverIO')); // outputs: "WebdriverIO is the best"
+```
+
+## Tag Name
+
+To query an element with a specific tag name use `<tag>` or `<tag />`
+
+## Name Attribute
+
+For querying elements with a specific name attribute you can either use a normal CSS3 selector or the
+provided name strategy from the JsonWireProtocol by passing something like `[name="some-name"]` as
+selector parameter
+
+## xPath
+
+It is also possible to query elements via a specific xPath. The selector has to have a format like
+for example `//BODY/DIV[6]/DIV[1]/SPAN[1]`
+
+In near future WebdriverIO will cover more selector features like form selector (e.g. `:password`,`:file` etc)
+or positional selectors like `:first` or `:nth`.
+
+## Mobile Selectors
+
+For (hybrid/native) mobile testing you have to use mobile strategies and use the underlying device automation technology directly. This is especially useful when a test needs some fine-grained control over finding elements.
+
+### Android UiAutomator
+
+Android’s UI Automator framework provides a number of ways to find elements. You can use the [UI Automator API](https://developer.android.com/tools/testing-support-library/index.html#uia-apis), in particular the [UiSelector class](https://developer.android.com/reference/android/support/test/uiautomator/UiSelector.html) to locate elements. In Appium you send the Java code, as a string, to the server, which executes it in the application’s environment, returning the element or elements.
+
+```js
+var selector = 'new UiSelector().text("Cancel")).className("android.widget.Button")';
+browser.click('android=' + selector);
+```
+
+### iOS UIAutomation
+
+When automating an iOS application, Apple’s [UI Automation framework](https://developer.apple.com/library/prerelease/tvos/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/UIAutomation.html) can be used to find elements. This JavaScript [API](https://developer.apple.com/library/ios/documentation/DeveloperTools/Reference/UIAutomationRef/index.html#//apple_ref/doc/uid/TP40009771) has methods to access to the view and everything on it.
+
+```js
+var selector = 'UIATarget.localTarget().frontMostApp().mainWindow().buttons()[0]'
+browser.click('ios=' + selector);
+```
+
+You can also use predicate searching within iOS UI Automation in Appium, to control element finding even further. See [here](https://github.com/appium/appium/blob/master/docs/en/writing-running-appium/ios_predicate.md) for details.
+
+### Accessibility ID
+
+The `accessibility id` locator strategy is designed to read a unique identifier for a UI element. This has the benefit of not changing during localization or any other process that might change text. In addition, it can be an aid in creating cross-platform tests, if elements that are functionally the same have the same accessibility id.
+
+- For iOS this is the `accessibility identifier` laid out by Apple [here](https://developer.apple.com/library/prerelease/ios/documentation/UIKit/Reference/UIAccessibilityIdentification_Protocol/index.html).
+- For Android the `accessibility id` maps to the `content-description` for the element, as described [here](https://developer.android.com/training/accessibility/accessible-app.html).
+
+For both platforms getting an element, or multiple elements, by their `accessibility id` is usually the best method. It is also the preferred way, in replacement of the deprecated `name` strategy.
+
+```js
+browser.click(`~my_accessibility_identifier`);
+```
+
+### Class Name
+
+The `class name` strategy is a `string` representing a UI element on the current view.
+
+- For iOS it is the full name of a [UIAutomation class](https://developer.apple.com/library/prerelease/tvos/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/UIAutomation.html), and will begin with `UIA-`, such as `UIATextField` for a text field. A full reference can be found [here](https://developer.apple.com/library/ios/navigation/#section=Frameworks&topic=UIAutomation).
+- For Android it is the fully qualified name of a [UI Automator](https://developer.android.com/tools/testing-support-library/index.html#UIAutomator) [class](https://developer.android.com/reference/android/widget/package-summary.html), such `android.widget.EditText` for a text field. A full reference can be found [here](https://developer.android.com/reference/android/widget/package-summary.html).
+
+```js
+// iOS example
+browser.click(`UIATextField`);
+// Android example
+browser.click(`android.widget.DatePicker`);
+```
+
+## Chain Selectors
+
+If you want to be more specific in your query, you can chain your selector until you've found the right
+element. If you call element before your actual command, WebdriverIO starts query from that element. For example
+if you have a DOM structure like:
+
+```html
+<div class="row">
+  <div class="entry">
+    <label>Product A</label>
+    <button>Add to cart</button>
+    <button>More Information</button>
+  </div>
+  <div class="entry">
+    <label>Product B</label>
+    <button>Add to cart</button>
+    <button>More Information</button>
+  </div>
+  <div class="entry">
+    <label>Product C</label>
+    <button>Add to cart</button>
+    <button>More Information</button>
+  </div>
+</div>
+```
+
+And you want to add product B to the cart it would be difficult to do that just by using the CSS selector.
+With selector chaining it gets way easier as you can narrow down the desired element step by step:
+
+```js
+browser.element('.row .entry:nth-child(1)').click('button*=Add');
+```

static/js/ketcher2/node_modules/webdriverio/docs/guide/usage/seleniumgrid.md

@@ -0,0 +1,68 @@
+name: seleniumgrid
+category: usage
+tags: guide
+index: 7
+title: WebdriverIO - Selenium Grid
+---
+
+Selenium Grid
+=====================
+
+As well as JSONWire protocol bindings, Webdriverio also offers a few utility commands for working with the Selenium Grid. It's often useful to know the details of the Grid node which is actually running the current session. Use `getGridNodeDetails()` to get a JSON object with details like ID, hostname and port, configured timeouts, plus any command-line params used to start the node.
+
+```js
+var gridDetails = browser.getGridNodeDetails();
+console.log(gridDetails);
+/**
+ * returns:
+ *
+ * { request:
+ *    { configuration:
+ *       { port: 5557,
+ *         nodeConfig: '/path/to/config.json',
+ *         servlets: [],
+ *         host: '192.168.2.1',
+ *         cleanUpCycle: 2000,
+ *         browserTimeout: 120000,
+ *         hubHost: 'example.com',
+ *         registerCycle: 10000,
+ *         capabilityMatcher: 'org.openqa.grid.internal.utils.DefaultCapabilityMatcher',
+ *         newSessionWaitTimeout: -1,
+ *         url: 'http://example.com:5557',
+ *         remoteHost: 'http://example.com:5557',
+ *         register: true,
+ *         id: 'MacMiniA10',
+ *         throwOnCapabilityNotPresent: true,
+ *         nodePolling: 2000,
+ *         proxy: 'org.openqa.grid.selenium.proxy.DefaultRemoteProxy',
+ *         maxSession: 4,
+ *         role: 'node',
+ *         jettyMaxThreads: -1,
+ *         nodeTimeout: 120,
+ *         hubPort: 80,
+ *         timeout: 90000 },
+ *      capabilities:
+ *       [ { seleniumProtocol: 'WebDriver',
+ *           platform: 'MAC',
+ *           firefoxVersion: '42',
+ *           browserName: 'firefox',
+ *           maxInstances: 2,
+ *           version: 'latest' },
+ *         { seleniumProtocol: 'WebDriver',
+ *           platform: 'MAC',
+ *           browserName: 'chrome',
+ *           maxInstances: 8,
+ *           chromeVersion: '46',
+ *           version: 'latest' },
+ *         { seleniumProtocol: 'WebDriver',
+ *           platform: 'MAC',
+ *           browserName: 'safari',
+ *           maxInstances: 1,
+ *           version: 'latest' } ] },
+ *   session: '33c2d04d-6bc1-424e-ba6f-63c400114554',
+ *   internalKey: 'd710b167-6f29-4097-a15c-7f7bbdb73edb',
+ *   inactivityTime: 78,
+ *   proxyId: 'MacMiniA10' }
+ *
+ */
+```

static/js/ketcher2/node_modules/webdriverio/docs/guide/usage/transferpromises.md

@@ -0,0 +1,41 @@
+name: transferpromises
+category: usage
+tags: guide
+index: 5
+title: WebdriverIO - Transfer Promises
+---
+
+Transfer Promises
+=================
+
+Per default the wdio testrunner transforms all commands to act like real synchronous commands. This way you don't need to deal with promises in any way. However if you don't use the wdio test runner or you have this behavior disabled you can use neat features of promises to write expressive tests with promise-based assertion libraries like [chai-as-promised](https://github.com/domenic/chai-as-promised/).
+
+```js
+var client = require('webdriverio').remote({
+    desiredCapabilities: {
+        browserName: 'chrome'
+    }
+});
+ 
+var chai = require('chai');
+var chaiAsPromised = require('chai-as-promised');
+
+chai.Should();
+chai.use(chaiAsPromised);
+chaiAsPromised.transferPromiseness = client.transferPromiseness;
+ 
+describe('my app', function() {
+    before(function () {
+        return client.init();
+    });
+ 
+    it('should contain a certain text after clicking', function() {
+        return client
+            .click('button=Send')
+            .isVisible('#status_message').should.eventually.be.true
+            .getText('#status_message').should.eventually.be.equal('Message sent!');
+    });
+});
+```
+
+The example above shows a simple integration test where a user clicks on a "Send" button and a message gets sent. The test checks if a status message gets displayed with a certain text. By setting the `transferPromiseness` function to the internal correspondent of WebdriverIO you can start chaining assertions together with commands.

static/js/ketcher2/node_modules/webdriverio/docs/index.md

@@ -0,0 +1,166 @@
+layout: start
+---
+
+<aside class="teaser">
+    <div class="teaserbox">
+        <h3>Extendable</h3>
+        <p>
+            Adding helper functions, or more complicated sets and combi-<br>nations of existing
+            commands is **simple** and really **useful**
+        </p>
+    </div>
+    <div class="teaserbox">
+        <h3>Compatible</h3>
+        <p>
+            WebdriverIO works in combination with most of the **TDD** and **BDD** test frameworks
+            in the JavaScript world
+        </p>
+    </div>
+    <div class="teaserbox">
+        <h3>Feature-Rich</h3>
+        <p>
+            It implements all Webdriver protocol commands and provides **useful integrations** with other tools.
+        </p>
+    </div>
+</aside>
+
+<aside class="features">
+    <ul>
+        <li>synchronous command handling</li>
+        <li>supports a variety of hooks</li>
+        <li>command line interface support</li>
+    </ul>
+    <ul>
+        <li><a href="https://twitter.com/webdriverio/status/806911722682544128" target="_blank">REPL interface</a></li>
+        <li><a href="http://gulpjs.com/">Gulp</a> and <a href="http://gruntjs.com/">Grunt</a> support</li>
+        <li>selector chaining</li>
+    </ul>
+</aside>
+
+<div class="rulethemall">
+    <h2 class="text-align">One Tool To Rule Them All:</h2>
+    <a href="https://github.com/webdriverio/grunt-webdriver"><img src="/images/plugins/grunt.png" alt="Grunt Integration"></a>
+    <a href="https://github.com/webdriverio/gulp-webdriver"><img src="/images/plugins/gulp.png" alt="Gulp Integration"></a>
+    <a href="https://atom.io/packages/webdriverio-snippets"><img src="http://webdriver.io/images/plugins/atom.png" alt="Atom snippets for WebdriverIO API"></a>
+    <a href="https://packagecontrol.io/packages/WebdriverIO"><img src="/images/plugins/sublime.png" alt="Sublime Text Plugin"></a>
+    <a href="https://github.com/webdriverio/webdrivercss#applitools-eyes-support"><img src="/images/plugins/applitools.png" alt="Visual Regression Testing with Applitools Eyes"></a>
+    <a href="https://github.com/webdriverio/webdriverrtc"><img src="/images/plugins/webrtc.png" alt="WebRTC Analytics Plugin"></a>
+</div>
+
+
+## What is WebdriverIO?
+
+<div style="overflow: hidden">
+    <article class="col2">
+        WebdriverIO lets you control a browser or a mobile application with just a few lines of code. Your test code will look simple, concise and easy to read. The integrated test runner let you write asynchronous commands in a synchronous way so that you don't need to care about how to handle a Promise to avoid racing conditions. Additionally it takes away all the cumbersome setup work and manages the Selenium session for you.<br>
+        <br>
+        Working with elements on a page has never been easier due to its synchronous nature. When fetching or looping over elements you can use just native JavaScript functions. With the `$` and `$$` functions WebdriverIO provides useful shortcuts which can also be chained in order to move deeper in the DOM tree without using complex xPath selectors.<br>
+        <br>
+        The test runner also comes with a variety of hooks that allow you to interfere into the test process in order to e.g. take screenshots if an error occurs or modify the test procedure according to a previous test result. This is used by WebdriverIOs [services](/guide/services/appium.html) to integrate your tests with 3rd party tools like [Appium](http://appium.io/).
+    </article>
+
+    <article class="runyourtests col2 last">
+```js
+var expect = require('chai').expect;
+describe('webdriver.io api page', function() {
+    it('should be able to filter for commands', function () {
+        browser.url('http://webdriver.io/api.html');
+
+        // filtering property commands
+        $('.searchbar input').setValue('getT');
+
+        // get all results that are displayed
+        var results = $$('.commands.property a').filter(function (link) {
+            return link.isVisible();
+        });
+
+        // assert number of results
+        expect(results.length).to.be.equal(3);
+
+        // check out second result
+        results[1].click();
+        expect($('.doc h1').getText()).to.be.equal('GETTEXT');
+    });
+});
+```
+    </article>
+</div>
+
+<a href="/guide.html" class="button getstarted">Get Started</a>
+<div class="testimonials"></div>
+
+<div style="overflow: hidden">
+    <article class="col2 standalone">
+```js
+var webdriverio = require('webdriverio');
+var options = { desiredCapabilities: { browserName: 'chrome' } };
+var client = webdriverio.remote(options);
+
+client
+    .init()
+    .url('https://duckduckgo.com/')
+    .setValue('#search_form_input_homepage', 'WebdriverIO')
+    .click('#search_button_homepage')
+    .getTitle().then(function(title) {
+        console.log('Title is: ' + title);
+
+        // outputs:
+        // "Title is: WebdriverIO (Software) at DuckDuckGo"
+    })
+    .end();
+```
+    </article>
+    <article class="col2 last">
+        <h2 class="right-col-heading">WebdriverIO as standalone package</h2>
+        <p>
+            WebdriverIO was designed to be as flexible and framework agnostic as possible. It can be applied in any context and serves not only the purpose of testing.<br>
+            <br>
+            You can use it as scrapper tool to dynamically fetch website data in an automated way or integrate it in your own automation library. Popular examples of that are [Spectron](http://electron.atom.io/spectron/), [Chimp](https://chimp.readme.io/) or [CodeceptJS](http://codecept.io/).
+            <div>
+                <p>
+                    <a href="http://electron.atom.io/spectron/" style="margin-right: 15px"><img src="http://electron.atom.io/images/spectron-icon.svg" width="75" /></a>
+                    <a href="https://chimp.readme.io/" style="margin-right: 15px"><img src="https://www.filepicker.io/api/file/C4MBXB4jQ6Ld9gII5IkF" /></a>
+                    <a href="http://codecept.io/"><img src="http://codecept.io/images/cjs-base.png" width="80" /></a>
+                </p>
+            </div>
+        </p>
+    </article>
+</div>
+
+## Easy Test Setup
+
+The `wdio` command line interface comes with a nice configuration utility that helps you to
+create your config file in less than a minute. It also gives and overview of all available
+3rd party packages like framework adaptions, reporter and services and installs them for you.
+
+
+<div class="cliwindow">
+![WDIO configuration utility](/images/config-utility.gif "WDIO configuration utility")
+</div>
+
+<div>
+    <article class="col2">
+        <h2>How does it work?</h2>
+        <p>
+            WebdriverIO is an open source testing utility for nodejs. It makes it possible to write super easy selenium tests with Javascript in your favorite BDD or TDD test framework.
+        </p>
+        <p>
+            It basically sends requests to a Selenium server via the <a href="https://www.w3.org/TR/webdriver/">WebDriver Protocol</a> and handles its response. These requests are wrapped in useful commands and can be used to test several aspects of your site in an automated way.
+        </p>
+    </article>
+
+    <article class="runyourtests col2 last">
+        <h2>Run your tests in the cloud</h2>
+        <p>
+            Services like Sauce Labs or BrowserStack provide selenium testing on remote hosts. Be able to run tests on a wide collection of platforms, devices and browser combinations without any configuration in your environment.
+        </p>
+        <div>
+            <p>WebdriverIO supports services including:</p>
+            <p>
+                <a href="https://saucelabs.com">Sauce Labs</a>
+                <a href="http://www.browserstack.com/">BrowserStack</a>
+                <a href="http://www.testingbot.com/">TestingBot</a>
+            </p>
+        </div>
+    </article>
+</div>