This upgrades us to TypeScript 3.1.1, which fixes some build failures. Annoyingly TypeScript does a better job of checking `process.stdio`, which exposes that the DefinitelyTyped definition for it is wrong. See https://github.com/DefinitelyTyped/DefinitelyTyped/issues/11587. I'll look into submitting a patch for that later.
This patch:
- adds experimental "transport" option to pptr.connect
- uses "transport" option to make sure Puppeteer-Web works with
Target.exposeDevToolsProtocol
Drive-by: add `browser.target()` to access browser target.
This patch introduces API to manage frame navigations.
As a drive-by, the `response.frame()` method is added as a shortcut
for `response.request().frame()`.
Fixes#2918.
This patch traces all public async methods and wraps them
in a helper method that tags the sync stack trace.
Later on, if the method call throws an exception, we add
a captured stack trace to the original stack trace with the "--ASYNC--"
heading.
An example of a stack trace:
```
Error: net::ERR_ABORTED at http://localhost:8907/empty.html
at navigate (/Users/lushnikov/prog/puppeteer/lib/Page.js:622:37)
at process._tickCallback (internal/process/next_tick.js:68:7)
-- ASYNC --
at Page.<anonymous> (/Users/lushnikov/prog/puppeteer/lib/helper.js:147:27)
at fit (/Users/lushnikov/prog/puppeteer/test/page.spec.js:546:18)
at process._tickCallback (internal/process/next_tick.js:68:7)
```
This patch:
- moves implementation of page.goto and page.waitForNavigation
into FrameManager. The defaultNavigationTimeout gets moved to
FrameManager as well.
- moves NavigatorWatcher into FrameManager to avoid circular dependency
References #2918
This patch unifies logic in response trackign in page.goto and
page.waitForNavigation.
As a drive-by, we now make sure that we return the right response
for the right frame. This will come handy for future frame navigation
API.
References #2918
This patch:
- adds "browser" field to the package.json with default
bundling options.
- introduces "bundle" and "unit-bundle" commands to
create bundle and test bundle
- starts running bundle tests on Travis Node 8 bots
Fixes#2374.
Bundled version of Puppeteer should rely on native WebSocket.
Luckily, 'ws' module supports the same interface as the native
browser websockets. This patch switches WebSocketTransport to
use the browser-compliant interface of 'ws'.
After this patch, I was able to bundle Puppeteer for browser
using the following config in `package.json`:
```json
"browser": {
"./lib/BrowserFetcher.js": false,
"ws": "./lib/BrowserWebSocket",
"fs": false,
"child_process": false,
"rimraf": false,
"readline": false
}
```
where `./lib/BrowserWebSocket` is:
```js
module.exports = WebSocket;
```
and the bundling command is:
```sh
$ browserify -r ./index.js:puppeteer > ppweb.js
```
References #2119
Currently connection assumes that transport is a websocket
and tries to handle websocket-related errors.
This patch:
- moves ConnectionTransport interface to use callbacks instead
of events. This way it could be used in browser context as well.
- introduces WebSocketTransport that implements ConnectionTransport
interface for ws.
This is a preparation step for 2 things:
- exposing `transport` option in the `puppeteer.connect` method
- better support for `browserify`
References #2119
When we merge commits to master, Travis kicks job to build a new commit
and to publish new version of puppeteer@next.
If two commits are landed in almost the same time, then travis starts
two parallel jobs to build each commit. This race condition results
in the incorrect puppeteer@next revision.
This patch teaches apply_next_version.js to verify if current HEAD
is matching upstream HEAD. If it doesn't, the predeploy hook fails
which (hopefully) aborts deployment.
Fixes#2925.
This patch removes all dynamic requires in Puppeteer. This should
make it much simpler to bundle puppeteer/puppeteer-core packages.
We used dynamic requires in a few places in lib/:
- BrowserFetcher was choosing between `http` and `https` based on some
runtime value. This was easy to fix with explicit `require`.
- BrowserFetcher and Launcher needed to know project root to store
chromium revisions and to read package name and chromium revision from
package.json. (projectRoot value would be different in node6).
Instead of doing a backwards logic to infer these
variables, we now pass them directly from `//index.js`.
With this patch, I was able to bundle Puppeteer using browserify and
the following config in `package.json`:
```json
"browser": {
"./lib/BrowserFetcher.js": false,
"ws": "./lib/BrowserWebSocket",
"fs": false,
"child_process": false,
"rimraf": false,
"readline": false
}
```
(where `lib/BrowserWebSocket.js` is a courtesy of @Janpot from
https://github.com/GoogleChrome/puppeteer/pull/2374/)
And command:
```sh
$ browserify -r puppeteer:./index.js > ppweb.js
```
References #2119
We had (and still have) a ton of pull requests to support
PUPPETEER_EXECUTABLE_PATH and PUPPETEER_CHROMIUM_REVISION in puppeteer launcher.
We were hesitant before since env variables are not scoped
and thus don't make a good interface for a library. Now, since we
determined `puppeteer-core` as a library and `puppeteer` as our end-user
product, it's safe to satisfy our user needs.
This patch:
- teaches PUPPETEER_EXECUTABLE_PATH and PUPPETEER_CHROMIUM_REVISION
env variables to control how Puppeteer launches browser
- makes sure these variables play no role in `puppeteer-core` package.
One of our checks makes sure all links from README.md to API.md
point to the last-released version of the API.
This sometimes doesn't work: when we refer to a section
in api.md that is just added, we should be able to reference
the "master" version of the api.md
This patch:
- teaches the doclint check to keep links to tip-of-tree version
of api.md in README.md intact.
- starts refering to tip-of-tree version of api.md in `puppeter-core` section
Before v1.7.0 we were creating Response objects either from protocol's
Network.Response struct, or from the data available in the
requestIntercepted.
With the recent chagens to the request interception logic, we can
always create response from Newtork.Response struct; this allows
us to simply create Response objects from protocol payload.
