2017-10-06 22:35:02 +00:00
|
|
|
/**
|
|
|
|
* Copyright 2017 Google Inc. All rights reserved.
|
|
|
|
*
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
* You may obtain a copy of the License at
|
|
|
|
*
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
*
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
* limitations under the License.
|
|
|
|
*/
|
|
|
|
|
2020-07-13 09:22:26 +00:00
|
|
|
import { assert } from './assert.js';
|
|
|
|
import { helper } from './helper.js';
|
|
|
|
import { createJSHandle, JSHandle, ElementHandle } from './JSHandle.js';
|
|
|
|
import { CDPSession } from './Connection.js';
|
|
|
|
import { DOMWorld } from './DOMWorld.js';
|
|
|
|
import { Frame } from './FrameManager.js';
|
2020-07-10 10:51:52 +00:00
|
|
|
import { Protocol } from 'devtools-protocol';
|
2020-07-13 09:22:26 +00:00
|
|
|
import { EvaluateHandleFn, SerializableOrJSHandle } from './EvalTypes.js';
|
chore: migrate src/ExecutionContext (#5705)
* chore: migrate src/ExecutionContext to TypeScript
I spent a while trying to decide on the best course of action for
typing the `evaluate` function.
Ideally I wanted to use generics so that as a user you could type
something like:
```
handle.evaluate<HTMLElement, number, boolean>((node, x) => true, 5)
```
And have TypeScript know the arguments of `node` and `x` based on those
generics. But I hit two problems with that:
* you have to have n overloads of `evaluate` to cope for as many number
of arguments as you can be bothered too (e.g. we'd need an overload for
1 arg, 2 args, 3 args, etc)
* I decided it's actually confusing because you don't know as a user
what those generics actually map to.
So in the end I went with one generic which is the return type of the
function:
```
handle.evaluate<boolean>((node, x) => true, 5)
```
And `node` and `x` get typed as `any` which means you can tell TS
yourself:
```
handle.evaluate<boolean>((node: HTMLElement, x: number) => true, 5)
```
I'd like to find a way to force that the arguments after the function do
match the arguments you've given (in the above example, TS would moan if
I swapped that `5` for `"foo"`), but I tried a few things and to be
honest the complexity of the types wasn't worth it, I don't think.
I'm very open to tweaking these but I'd rather ship this and tweak going
forwards rather than spend hours now tweaking. Once we ship these
typedefs and get feedback from the community I'm sure we can improve
them.
2020-04-22 09:33:44 +00:00
|
|
|
|
|
|
|
export const EVALUATION_SCRIPT_URL = '__puppeteer_evaluation_script__';
|
2018-07-12 01:38:34 +00:00
|
|
|
const SOURCE_URL_REGEX = /^[\040\t]*\/\/[@#] sourceURL=\s*(\S*?)\s*$/m;
|
|
|
|
|
2020-06-24 15:11:10 +00:00
|
|
|
/**
|
|
|
|
* This class represents a context for JavaScript execution. A [Page] might have
|
|
|
|
* many execution contexts:
|
|
|
|
* - each
|
|
|
|
* {@link https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe |
|
|
|
|
* frame } has "default" execution context that is always created after frame is
|
|
|
|
* attached to DOM. This context is returned by the
|
|
|
|
* {@link frame.executionContext()} method.
|
|
|
|
* - {@link https://developer.chrome.com/extensions | Extension}'s content scripts
|
|
|
|
* create additional execution contexts.
|
|
|
|
*
|
|
|
|
* Besides pages, execution contexts can be found in
|
|
|
|
* {@link https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API |
|
|
|
|
* workers }.
|
|
|
|
*
|
|
|
|
* @public
|
|
|
|
*/
|
chore: migrate src/ExecutionContext (#5705)
* chore: migrate src/ExecutionContext to TypeScript
I spent a while trying to decide on the best course of action for
typing the `evaluate` function.
Ideally I wanted to use generics so that as a user you could type
something like:
```
handle.evaluate<HTMLElement, number, boolean>((node, x) => true, 5)
```
And have TypeScript know the arguments of `node` and `x` based on those
generics. But I hit two problems with that:
* you have to have n overloads of `evaluate` to cope for as many number
of arguments as you can be bothered too (e.g. we'd need an overload for
1 arg, 2 args, 3 args, etc)
* I decided it's actually confusing because you don't know as a user
what those generics actually map to.
So in the end I went with one generic which is the return type of the
function:
```
handle.evaluate<boolean>((node, x) => true, 5)
```
And `node` and `x` get typed as `any` which means you can tell TS
yourself:
```
handle.evaluate<boolean>((node: HTMLElement, x: number) => true, 5)
```
I'd like to find a way to force that the arguments after the function do
match the arguments you've given (in the above example, TS would moan if
I swapped that `5` for `"foo"`), but I tried a few things and to be
honest the complexity of the types wasn't worth it, I don't think.
I'm very open to tweaking these but I'd rather ship this and tweak going
forwards rather than spend hours now tweaking. Once we ship these
typedefs and get feedback from the community I'm sure we can improve
them.
2020-04-22 09:33:44 +00:00
|
|
|
export class ExecutionContext {
|
2020-06-24 15:11:10 +00:00
|
|
|
/**
|
|
|
|
* @internal
|
|
|
|
*/
|
chore: migrate src/ExecutionContext (#5705)
* chore: migrate src/ExecutionContext to TypeScript
I spent a while trying to decide on the best course of action for
typing the `evaluate` function.
Ideally I wanted to use generics so that as a user you could type
something like:
```
handle.evaluate<HTMLElement, number, boolean>((node, x) => true, 5)
```
And have TypeScript know the arguments of `node` and `x` based on those
generics. But I hit two problems with that:
* you have to have n overloads of `evaluate` to cope for as many number
of arguments as you can be bothered too (e.g. we'd need an overload for
1 arg, 2 args, 3 args, etc)
* I decided it's actually confusing because you don't know as a user
what those generics actually map to.
So in the end I went with one generic which is the return type of the
function:
```
handle.evaluate<boolean>((node, x) => true, 5)
```
And `node` and `x` get typed as `any` which means you can tell TS
yourself:
```
handle.evaluate<boolean>((node: HTMLElement, x: number) => true, 5)
```
I'd like to find a way to force that the arguments after the function do
match the arguments you've given (in the above example, TS would moan if
I swapped that `5` for `"foo"`), but I tried a few things and to be
honest the complexity of the types wasn't worth it, I don't think.
I'm very open to tweaking these but I'd rather ship this and tweak going
forwards rather than spend hours now tweaking. Once we ship these
typedefs and get feedback from the community I'm sure we can improve
them.
2020-04-22 09:33:44 +00:00
|
|
|
_client: CDPSession;
|
2020-06-24 15:11:10 +00:00
|
|
|
/**
|
|
|
|
* @internal
|
|
|
|
*/
|
2020-04-28 16:45:55 +00:00
|
|
|
_world: DOMWorld;
|
2020-10-07 08:49:11 +00:00
|
|
|
/**
|
|
|
|
* @internal
|
|
|
|
*/
|
|
|
|
_contextId: number;
|
2021-01-25 12:01:59 +00:00
|
|
|
/**
|
|
|
|
* @internal
|
|
|
|
*/
|
|
|
|
_contextName: string;
|
chore: migrate src/ExecutionContext (#5705)
* chore: migrate src/ExecutionContext to TypeScript
I spent a while trying to decide on the best course of action for
typing the `evaluate` function.
Ideally I wanted to use generics so that as a user you could type
something like:
```
handle.evaluate<HTMLElement, number, boolean>((node, x) => true, 5)
```
And have TypeScript know the arguments of `node` and `x` based on those
generics. But I hit two problems with that:
* you have to have n overloads of `evaluate` to cope for as many number
of arguments as you can be bothered too (e.g. we'd need an overload for
1 arg, 2 args, 3 args, etc)
* I decided it's actually confusing because you don't know as a user
what those generics actually map to.
So in the end I went with one generic which is the return type of the
function:
```
handle.evaluate<boolean>((node, x) => true, 5)
```
And `node` and `x` get typed as `any` which means you can tell TS
yourself:
```
handle.evaluate<boolean>((node: HTMLElement, x: number) => true, 5)
```
I'd like to find a way to force that the arguments after the function do
match the arguments you've given (in the above example, TS would moan if
I swapped that `5` for `"foo"`), but I tried a few things and to be
honest the complexity of the types wasn't worth it, I don't think.
I'm very open to tweaking these but I'd rather ship this and tweak going
forwards rather than spend hours now tweaking. Once we ship these
typedefs and get feedback from the community I'm sure we can improve
them.
2020-04-22 09:33:44 +00:00
|
|
|
|
2020-06-24 15:11:10 +00:00
|
|
|
/**
|
|
|
|
* @internal
|
|
|
|
*/
|
2020-05-07 10:54:55 +00:00
|
|
|
constructor(
|
|
|
|
client: CDPSession,
|
|
|
|
contextPayload: Protocol.Runtime.ExecutionContextDescription,
|
|
|
|
world: DOMWorld
|
|
|
|
) {
|
2017-10-06 22:35:02 +00:00
|
|
|
this._client = client;
|
2019-01-22 22:55:33 +00:00
|
|
|
this._world = world;
|
2017-11-19 00:27:52 +00:00
|
|
|
this._contextId = contextPayload.id;
|
2021-01-25 12:01:59 +00:00
|
|
|
this._contextName = contextPayload.name;
|
2017-10-06 22:35:02 +00:00
|
|
|
}
|
|
|
|
|
2020-06-24 15:11:10 +00:00
|
|
|
/**
|
|
|
|
* @remarks
|
|
|
|
*
|
|
|
|
* Not every execution context is associated with a frame. For
|
|
|
|
* example, workers and extensions have execution contexts that are not
|
|
|
|
* associated with frames.
|
|
|
|
*
|
|
|
|
* @returns The frame associated with this execution context.
|
|
|
|
*/
|
2020-04-29 11:28:16 +00:00
|
|
|
frame(): Frame | null {
|
2019-01-22 22:55:33 +00:00
|
|
|
return this._world ? this._world.frame() : null;
|
2018-02-13 22:02:44 +00:00
|
|
|
}
|
|
|
|
|
2020-06-24 15:11:10 +00:00
|
|
|
/**
|
|
|
|
* @remarks
|
|
|
|
* If the function passed to the `executionContext.evaluate` returns a
|
|
|
|
* Promise, then `executionContext.evaluate` would wait for the promise to
|
|
|
|
* resolve and return its value. If the function passed to the
|
|
|
|
* `executionContext.evaluate` returns a non-serializable value, then
|
|
|
|
* `executionContext.evaluate` resolves to `undefined`. DevTools Protocol also
|
|
|
|
* supports transferring some additional values that are not serializable by
|
|
|
|
* `JSON`: `-0`, `NaN`, `Infinity`, `-Infinity`, and bigint literals.
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* @example
|
|
|
|
* ```js
|
|
|
|
* const executionContext = await page.mainFrame().executionContext();
|
|
|
|
* const result = await executionContext.evaluate(() => Promise.resolve(8 * 7))* ;
|
|
|
|
* console.log(result); // prints "56"
|
|
|
|
* ```
|
|
|
|
*
|
|
|
|
* @example
|
|
|
|
* A string can also be passed in instead of a function.
|
|
|
|
*
|
|
|
|
* ```js
|
|
|
|
* console.log(await executionContext.evaluate('1 + 2')); // prints "3"
|
|
|
|
* ```
|
|
|
|
*
|
|
|
|
* @example
|
|
|
|
* {@link JSHandle} instances can be passed as arguments to the
|
|
|
|
* `executionContext.* evaluate`:
|
|
|
|
* ```js
|
|
|
|
* const oneHandle = await executionContext.evaluateHandle(() => 1);
|
|
|
|
* const twoHandle = await executionContext.evaluateHandle(() => 2);
|
|
|
|
* const result = await executionContext.evaluate(
|
|
|
|
* (a, b) => a + b, oneHandle, * twoHandle
|
|
|
|
* );
|
|
|
|
* await oneHandle.dispose();
|
|
|
|
* await twoHandle.dispose();
|
|
|
|
* console.log(result); // prints '3'.
|
|
|
|
* ```
|
|
|
|
* @param pageFunction a function to be evaluated in the `executionContext`
|
|
|
|
* @param args argument to pass to the page function
|
|
|
|
*
|
|
|
|
* @returns A promise that resolves to the return value of the given function.
|
|
|
|
*/
|
2020-05-07 10:54:55 +00:00
|
|
|
async evaluate<ReturnType extends any>(
|
|
|
|
pageFunction: Function | string,
|
|
|
|
...args: unknown[]
|
|
|
|
): Promise<ReturnType> {
|
|
|
|
return await this._evaluateInternal<ReturnType>(
|
|
|
|
true,
|
|
|
|
pageFunction,
|
|
|
|
...args
|
|
|
|
);
|
2017-10-06 22:35:02 +00:00
|
|
|
}
|
|
|
|
|
2020-06-24 15:11:10 +00:00
|
|
|
/**
|
|
|
|
* @remarks
|
|
|
|
* The only difference between `executionContext.evaluate` and
|
|
|
|
* `executionContext.evaluateHandle` is that `executionContext.evaluateHandle`
|
|
|
|
* returns an in-page object (a {@link JSHandle}).
|
|
|
|
* If the function passed to the `executionContext.evaluateHandle` returns a
|
|
|
|
* Promise, then `executionContext.evaluateHandle` would wait for the
|
|
|
|
* promise to resolve and return its value.
|
|
|
|
*
|
|
|
|
* @example
|
|
|
|
* ```js
|
|
|
|
* const context = await page.mainFrame().executionContext();
|
|
|
|
* const aHandle = await context.evaluateHandle(() => Promise.resolve(self));
|
|
|
|
* aHandle; // Handle for the global object.
|
|
|
|
* ```
|
|
|
|
*
|
|
|
|
* @example
|
|
|
|
* A string can also be passed in instead of a function.
|
|
|
|
*
|
|
|
|
* ```js
|
|
|
|
* // Handle for the '3' * object.
|
|
|
|
* const aHandle = await context.evaluateHandle('1 + 2');
|
|
|
|
* ```
|
|
|
|
*
|
|
|
|
* @example
|
|
|
|
* JSHandle instances can be passed as arguments
|
|
|
|
* to the `executionContext.* evaluateHandle`:
|
|
|
|
*
|
|
|
|
* ```js
|
|
|
|
* const aHandle = await context.evaluateHandle(() => document.body);
|
|
|
|
* const resultHandle = await context.evaluateHandle(body => body.innerHTML, * aHandle);
|
|
|
|
* console.log(await resultHandle.jsonValue()); // prints body's innerHTML
|
|
|
|
* await aHandle.dispose();
|
|
|
|
* await resultHandle.dispose();
|
|
|
|
* ```
|
|
|
|
*
|
|
|
|
* @param pageFunction a function to be evaluated in the `executionContext`
|
|
|
|
* @param args argument to pass to the page function
|
|
|
|
*
|
|
|
|
* @returns A promise that resolves to the return value of the given function
|
|
|
|
* as an in-page object (a {@link JSHandle}).
|
|
|
|
*/
|
2020-07-01 11:44:08 +00:00
|
|
|
async evaluateHandle<HandleType extends JSHandle | ElementHandle = JSHandle>(
|
|
|
|
pageFunction: EvaluateHandleFn,
|
|
|
|
...args: SerializableOrJSHandle[]
|
|
|
|
): Promise<HandleType> {
|
|
|
|
return this._evaluateInternal<HandleType>(false, pageFunction, ...args);
|
2019-06-07 20:46:43 +00:00
|
|
|
}
|
|
|
|
|
2020-05-07 10:54:55 +00:00
|
|
|
private async _evaluateInternal<ReturnType>(
|
2020-07-01 11:44:08 +00:00
|
|
|
returnByValue: boolean,
|
2020-05-07 10:54:55 +00:00
|
|
|
pageFunction: Function | string,
|
|
|
|
...args: unknown[]
|
|
|
|
): Promise<ReturnType> {
|
2018-07-12 01:38:34 +00:00
|
|
|
const suffix = `//# sourceURL=${EVALUATION_SCRIPT_URL}`;
|
|
|
|
|
2017-10-06 22:35:02 +00:00
|
|
|
if (helper.isString(pageFunction)) {
|
|
|
|
const contextId = this._contextId;
|
chore: migrate src/ExecutionContext (#5705)
* chore: migrate src/ExecutionContext to TypeScript
I spent a while trying to decide on the best course of action for
typing the `evaluate` function.
Ideally I wanted to use generics so that as a user you could type
something like:
```
handle.evaluate<HTMLElement, number, boolean>((node, x) => true, 5)
```
And have TypeScript know the arguments of `node` and `x` based on those
generics. But I hit two problems with that:
* you have to have n overloads of `evaluate` to cope for as many number
of arguments as you can be bothered too (e.g. we'd need an overload for
1 arg, 2 args, 3 args, etc)
* I decided it's actually confusing because you don't know as a user
what those generics actually map to.
So in the end I went with one generic which is the return type of the
function:
```
handle.evaluate<boolean>((node, x) => true, 5)
```
And `node` and `x` get typed as `any` which means you can tell TS
yourself:
```
handle.evaluate<boolean>((node: HTMLElement, x: number) => true, 5)
```
I'd like to find a way to force that the arguments after the function do
match the arguments you've given (in the above example, TS would moan if
I swapped that `5` for `"foo"`), but I tried a few things and to be
honest the complexity of the types wasn't worth it, I don't think.
I'm very open to tweaking these but I'd rather ship this and tweak going
forwards rather than spend hours now tweaking. Once we ship these
typedefs and get feedback from the community I'm sure we can improve
them.
2020-04-22 09:33:44 +00:00
|
|
|
const expression = pageFunction;
|
2020-05-07 10:54:55 +00:00
|
|
|
const expressionWithSourceUrl = SOURCE_URL_REGEX.test(expression)
|
|
|
|
? expression
|
|
|
|
: expression + '\n' + suffix;
|
|
|
|
|
|
|
|
const { exceptionDetails, result: remoteObject } = await this._client
|
|
|
|
.send('Runtime.evaluate', {
|
|
|
|
expression: expressionWithSourceUrl,
|
|
|
|
contextId,
|
|
|
|
returnByValue,
|
|
|
|
awaitPromise: true,
|
|
|
|
userGesture: true,
|
|
|
|
})
|
|
|
|
.catch(rewriteError);
|
chore: migrate src/ExecutionContext (#5705)
* chore: migrate src/ExecutionContext to TypeScript
I spent a while trying to decide on the best course of action for
typing the `evaluate` function.
Ideally I wanted to use generics so that as a user you could type
something like:
```
handle.evaluate<HTMLElement, number, boolean>((node, x) => true, 5)
```
And have TypeScript know the arguments of `node` and `x` based on those
generics. But I hit two problems with that:
* you have to have n overloads of `evaluate` to cope for as many number
of arguments as you can be bothered too (e.g. we'd need an overload for
1 arg, 2 args, 3 args, etc)
* I decided it's actually confusing because you don't know as a user
what those generics actually map to.
So in the end I went with one generic which is the return type of the
function:
```
handle.evaluate<boolean>((node, x) => true, 5)
```
And `node` and `x` get typed as `any` which means you can tell TS
yourself:
```
handle.evaluate<boolean>((node: HTMLElement, x: number) => true, 5)
```
I'd like to find a way to force that the arguments after the function do
match the arguments you've given (in the above example, TS would moan if
I swapped that `5` for `"foo"`), but I tried a few things and to be
honest the complexity of the types wasn't worth it, I don't think.
I'm very open to tweaking these but I'd rather ship this and tweak going
forwards rather than spend hours now tweaking. Once we ship these
typedefs and get feedback from the community I'm sure we can improve
them.
2020-04-22 09:33:44 +00:00
|
|
|
|
2017-10-06 22:35:02 +00:00
|
|
|
if (exceptionDetails)
|
2020-05-07 10:54:55 +00:00
|
|
|
throw new Error(
|
|
|
|
'Evaluation failed: ' + helper.getExceptionMessage(exceptionDetails)
|
|
|
|
);
|
chore: migrate src/ExecutionContext (#5705)
* chore: migrate src/ExecutionContext to TypeScript
I spent a while trying to decide on the best course of action for
typing the `evaluate` function.
Ideally I wanted to use generics so that as a user you could type
something like:
```
handle.evaluate<HTMLElement, number, boolean>((node, x) => true, 5)
```
And have TypeScript know the arguments of `node` and `x` based on those
generics. But I hit two problems with that:
* you have to have n overloads of `evaluate` to cope for as many number
of arguments as you can be bothered too (e.g. we'd need an overload for
1 arg, 2 args, 3 args, etc)
* I decided it's actually confusing because you don't know as a user
what those generics actually map to.
So in the end I went with one generic which is the return type of the
function:
```
handle.evaluate<boolean>((node, x) => true, 5)
```
And `node` and `x` get typed as `any` which means you can tell TS
yourself:
```
handle.evaluate<boolean>((node: HTMLElement, x: number) => true, 5)
```
I'd like to find a way to force that the arguments after the function do
match the arguments you've given (in the above example, TS would moan if
I swapped that `5` for `"foo"`), but I tried a few things and to be
honest the complexity of the types wasn't worth it, I don't think.
I'm very open to tweaking these but I'd rather ship this and tweak going
forwards rather than spend hours now tweaking. Once we ship these
typedefs and get feedback from the community I'm sure we can improve
them.
2020-04-22 09:33:44 +00:00
|
|
|
|
2020-05-07 10:54:55 +00:00
|
|
|
return returnByValue
|
|
|
|
? helper.valueFromRemoteObject(remoteObject)
|
|
|
|
: createJSHandle(this, remoteObject);
|
2017-10-06 22:35:02 +00:00
|
|
|
}
|
|
|
|
|
2018-07-12 01:38:34 +00:00
|
|
|
if (typeof pageFunction !== 'function')
|
2020-05-07 10:54:55 +00:00
|
|
|
throw new Error(
|
|
|
|
`Expected to get |string| or |function| as the first argument, but got "${pageFunction}" instead.`
|
|
|
|
);
|
2018-07-12 01:38:34 +00:00
|
|
|
|
2018-11-01 23:43:21 +00:00
|
|
|
let functionText = pageFunction.toString();
|
|
|
|
try {
|
|
|
|
new Function('(' + functionText + ')');
|
2020-04-28 13:16:28 +00:00
|
|
|
} catch (error) {
|
2018-11-01 23:43:21 +00:00
|
|
|
// This means we might have a function shorthand. Try another
|
|
|
|
// time prefixing 'function '.
|
|
|
|
if (functionText.startsWith('async '))
|
2020-05-07 10:54:55 +00:00
|
|
|
functionText =
|
|
|
|
'async function ' + functionText.substring('async '.length);
|
|
|
|
else functionText = 'function ' + functionText;
|
2018-11-01 23:43:21 +00:00
|
|
|
try {
|
2020-05-07 10:54:55 +00:00
|
|
|
new Function('(' + functionText + ')');
|
2020-04-28 13:16:28 +00:00
|
|
|
} catch (error) {
|
2018-11-01 23:43:21 +00:00
|
|
|
// We tried hard to serialize, but there's a weird beast here.
|
|
|
|
throw new Error('Passed function is not well-serializable!');
|
|
|
|
}
|
|
|
|
}
|
2019-01-14 22:30:50 +00:00
|
|
|
let callFunctionOnPromise;
|
|
|
|
try {
|
|
|
|
callFunctionOnPromise = this._client.send('Runtime.callFunctionOn', {
|
|
|
|
functionDeclaration: functionText + '\n' + suffix + '\n',
|
|
|
|
executionContextId: this._contextId,
|
|
|
|
arguments: args.map(convertArgument.bind(this)),
|
2019-06-07 20:46:43 +00:00
|
|
|
returnByValue,
|
2019-01-14 22:30:50 +00:00
|
|
|
awaitPromise: true,
|
2020-05-07 10:54:55 +00:00
|
|
|
userGesture: true,
|
2019-01-14 22:30:50 +00:00
|
|
|
});
|
2020-04-28 13:16:28 +00:00
|
|
|
} catch (error) {
|
2020-05-07 10:54:55 +00:00
|
|
|
if (
|
|
|
|
error instanceof TypeError &&
|
|
|
|
error.message.startsWith('Converting circular structure to JSON')
|
|
|
|
)
|
2020-04-28 13:16:28 +00:00
|
|
|
error.message += ' Are you passing a nested JSHandle?';
|
|
|
|
throw error;
|
2019-01-14 22:30:50 +00:00
|
|
|
}
|
2020-05-07 10:54:55 +00:00
|
|
|
const {
|
|
|
|
exceptionDetails,
|
|
|
|
result: remoteObject,
|
|
|
|
} = await callFunctionOnPromise.catch(rewriteError);
|
2017-10-06 22:35:02 +00:00
|
|
|
if (exceptionDetails)
|
2020-05-07 10:54:55 +00:00
|
|
|
throw new Error(
|
|
|
|
'Evaluation failed: ' + helper.getExceptionMessage(exceptionDetails)
|
|
|
|
);
|
|
|
|
return returnByValue
|
|
|
|
? helper.valueFromRemoteObject(remoteObject)
|
|
|
|
: createJSHandle(this, remoteObject);
|
2017-10-06 22:35:02 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @param {*} arg
|
2020-06-12 10:38:24 +00:00
|
|
|
* @returns {*}
|
2018-08-06 18:31:33 +00:00
|
|
|
* @this {ExecutionContext}
|
2017-10-06 22:35:02 +00:00
|
|
|
*/
|
chore: migrate src/ExecutionContext (#5705)
* chore: migrate src/ExecutionContext to TypeScript
I spent a while trying to decide on the best course of action for
typing the `evaluate` function.
Ideally I wanted to use generics so that as a user you could type
something like:
```
handle.evaluate<HTMLElement, number, boolean>((node, x) => true, 5)
```
And have TypeScript know the arguments of `node` and `x` based on those
generics. But I hit two problems with that:
* you have to have n overloads of `evaluate` to cope for as many number
of arguments as you can be bothered too (e.g. we'd need an overload for
1 arg, 2 args, 3 args, etc)
* I decided it's actually confusing because you don't know as a user
what those generics actually map to.
So in the end I went with one generic which is the return type of the
function:
```
handle.evaluate<boolean>((node, x) => true, 5)
```
And `node` and `x` get typed as `any` which means you can tell TS
yourself:
```
handle.evaluate<boolean>((node: HTMLElement, x: number) => true, 5)
```
I'd like to find a way to force that the arguments after the function do
match the arguments you've given (in the above example, TS would moan if
I swapped that `5` for `"foo"`), but I tried a few things and to be
honest the complexity of the types wasn't worth it, I don't think.
I'm very open to tweaking these but I'd rather ship this and tweak going
forwards rather than spend hours now tweaking. Once we ship these
typedefs and get feedback from the community I'm sure we can improve
them.
2020-04-22 09:33:44 +00:00
|
|
|
function convertArgument(this: ExecutionContext, arg: unknown): unknown {
|
2020-05-07 10:54:55 +00:00
|
|
|
if (typeof arg === 'bigint')
|
|
|
|
// eslint-disable-line valid-typeof
|
|
|
|
return { unserializableValue: `${arg.toString()}n` };
|
|
|
|
if (Object.is(arg, -0)) return { unserializableValue: '-0' };
|
|
|
|
if (Object.is(arg, Infinity)) return { unserializableValue: 'Infinity' };
|
2017-10-06 22:35:02 +00:00
|
|
|
if (Object.is(arg, -Infinity))
|
2020-05-07 10:54:55 +00:00
|
|
|
return { unserializableValue: '-Infinity' };
|
|
|
|
if (Object.is(arg, NaN)) return { unserializableValue: 'NaN' };
|
|
|
|
const objectHandle = arg && arg instanceof JSHandle ? arg : null;
|
2017-10-06 22:35:02 +00:00
|
|
|
if (objectHandle) {
|
|
|
|
if (objectHandle._context !== this)
|
2020-05-07 10:54:55 +00:00
|
|
|
throw new Error(
|
|
|
|
'JSHandles can be evaluated only in the context they were created!'
|
|
|
|
);
|
|
|
|
if (objectHandle._disposed) throw new Error('JSHandle is disposed!');
|
2017-10-06 22:35:02 +00:00
|
|
|
if (objectHandle._remoteObject.unserializableValue)
|
2020-05-07 10:54:55 +00:00
|
|
|
return {
|
|
|
|
unserializableValue: objectHandle._remoteObject.unserializableValue,
|
|
|
|
};
|
2017-10-06 22:35:02 +00:00
|
|
|
if (!objectHandle._remoteObject.objectId)
|
2020-05-07 10:54:55 +00:00
|
|
|
return { value: objectHandle._remoteObject.value };
|
|
|
|
return { objectId: objectHandle._remoteObject.objectId };
|
2017-10-06 22:35:02 +00:00
|
|
|
}
|
2020-05-07 10:54:55 +00:00
|
|
|
return { value: arg };
|
2017-10-06 22:35:02 +00:00
|
|
|
}
|
2018-06-14 22:27:59 +00:00
|
|
|
|
2020-07-10 10:51:52 +00:00
|
|
|
function rewriteError(error: Error): Protocol.Runtime.EvaluateResponse {
|
2019-06-11 00:35:40 +00:00
|
|
|
if (error.message.includes('Object reference chain is too long'))
|
2020-05-07 10:54:55 +00:00
|
|
|
return { result: { type: 'undefined' } };
|
|
|
|
if (error.message.includes("Object couldn't be returned by value"))
|
|
|
|
return { result: { type: 'undefined' } };
|
|
|
|
|
|
|
|
if (
|
|
|
|
error.message.endsWith('Cannot find context with specified id') ||
|
|
|
|
error.message.endsWith('Inspected target navigated or closed')
|
|
|
|
)
|
|
|
|
throw new Error(
|
|
|
|
'Execution context was destroyed, most likely because of a navigation.'
|
|
|
|
);
|
2018-06-14 22:27:59 +00:00
|
|
|
throw error;
|
|
|
|
}
|
2017-10-06 22:35:02 +00:00
|
|
|
}
|
2017-10-11 21:41:20 +00:00
|
|
|
|
2020-06-24 15:11:10 +00:00
|
|
|
/**
|
|
|
|
* This method iterates the JavaScript heap and finds all the objects with the
|
|
|
|
* given prototype.
|
|
|
|
* @remarks
|
|
|
|
* @example
|
|
|
|
* ```js
|
|
|
|
* // Create a Map object
|
|
|
|
* await page.evaluate(() => window.map = new Map());
|
|
|
|
* // Get a handle to the Map object prototype
|
|
|
|
* const mapPrototype = await page.evaluateHandle(() => Map.prototype);
|
|
|
|
* // Query all map instances into an array
|
|
|
|
* const mapInstances = await page.queryObjects(mapPrototype);
|
|
|
|
* // Count amount of map objects in heap
|
|
|
|
* const count = await page.evaluate(maps => maps.length, mapInstances);
|
|
|
|
* await mapInstances.dispose();
|
|
|
|
* await mapPrototype.dispose();
|
|
|
|
* ```
|
|
|
|
*
|
|
|
|
* @param prototypeHandle a handle to the object prototype
|
|
|
|
*
|
|
|
|
* @returns A handle to an array of objects with the given prototype.
|
|
|
|
*/
|
chore: migrate src/ExecutionContext (#5705)
* chore: migrate src/ExecutionContext to TypeScript
I spent a while trying to decide on the best course of action for
typing the `evaluate` function.
Ideally I wanted to use generics so that as a user you could type
something like:
```
handle.evaluate<HTMLElement, number, boolean>((node, x) => true, 5)
```
And have TypeScript know the arguments of `node` and `x` based on those
generics. But I hit two problems with that:
* you have to have n overloads of `evaluate` to cope for as many number
of arguments as you can be bothered too (e.g. we'd need an overload for
1 arg, 2 args, 3 args, etc)
* I decided it's actually confusing because you don't know as a user
what those generics actually map to.
So in the end I went with one generic which is the return type of the
function:
```
handle.evaluate<boolean>((node, x) => true, 5)
```
And `node` and `x` get typed as `any` which means you can tell TS
yourself:
```
handle.evaluate<boolean>((node: HTMLElement, x: number) => true, 5)
```
I'd like to find a way to force that the arguments after the function do
match the arguments you've given (in the above example, TS would moan if
I swapped that `5` for `"foo"`), but I tried a few things and to be
honest the complexity of the types wasn't worth it, I don't think.
I'm very open to tweaking these but I'd rather ship this and tweak going
forwards rather than spend hours now tweaking. Once we ship these
typedefs and get feedback from the community I'm sure we can improve
them.
2020-04-22 09:33:44 +00:00
|
|
|
async queryObjects(prototypeHandle: JSHandle): Promise<JSHandle> {
|
2018-05-31 23:53:51 +00:00
|
|
|
assert(!prototypeHandle._disposed, 'Prototype JSHandle is disposed!');
|
2020-05-07 10:54:55 +00:00
|
|
|
assert(
|
|
|
|
prototypeHandle._remoteObject.objectId,
|
|
|
|
'Prototype JSHandle must not be referencing primitive value'
|
|
|
|
);
|
2017-10-11 21:41:20 +00:00
|
|
|
const response = await this._client.send('Runtime.queryObjects', {
|
2020-05-07 10:54:55 +00:00
|
|
|
prototypeObjectId: prototypeHandle._remoteObject.objectId,
|
2017-10-11 21:41:20 +00:00
|
|
|
});
|
2018-08-16 23:16:27 +00:00
|
|
|
return createJSHandle(this, response.objects);
|
2017-10-11 21:41:20 +00:00
|
|
|
}
|
2019-01-28 20:24:27 +00:00
|
|
|
|
2020-06-24 15:11:10 +00:00
|
|
|
/**
|
|
|
|
* @internal
|
|
|
|
*/
|
2020-05-07 10:54:55 +00:00
|
|
|
async _adoptBackendNodeId(
|
|
|
|
backendNodeId: Protocol.DOM.BackendNodeId
|
|
|
|
): Promise<ElementHandle> {
|
|
|
|
const { object } = await this._client.send('DOM.resolveNode', {
|
2020-01-27 13:44:53 +00:00
|
|
|
backendNodeId: backendNodeId,
|
|
|
|
executionContextId: this._contextId,
|
|
|
|
});
|
chore: migrate src/ExecutionContext (#5705)
* chore: migrate src/ExecutionContext to TypeScript
I spent a while trying to decide on the best course of action for
typing the `evaluate` function.
Ideally I wanted to use generics so that as a user you could type
something like:
```
handle.evaluate<HTMLElement, number, boolean>((node, x) => true, 5)
```
And have TypeScript know the arguments of `node` and `x` based on those
generics. But I hit two problems with that:
* you have to have n overloads of `evaluate` to cope for as many number
of arguments as you can be bothered too (e.g. we'd need an overload for
1 arg, 2 args, 3 args, etc)
* I decided it's actually confusing because you don't know as a user
what those generics actually map to.
So in the end I went with one generic which is the return type of the
function:
```
handle.evaluate<boolean>((node, x) => true, 5)
```
And `node` and `x` get typed as `any` which means you can tell TS
yourself:
```
handle.evaluate<boolean>((node: HTMLElement, x: number) => true, 5)
```
I'd like to find a way to force that the arguments after the function do
match the arguments you've given (in the above example, TS would moan if
I swapped that `5` for `"foo"`), but I tried a few things and to be
honest the complexity of the types wasn't worth it, I don't think.
I'm very open to tweaking these but I'd rather ship this and tweak going
forwards rather than spend hours now tweaking. Once we ship these
typedefs and get feedback from the community I'm sure we can improve
them.
2020-04-22 09:33:44 +00:00
|
|
|
return createJSHandle(this, object) as ElementHandle;
|
2020-01-27 13:44:53 +00:00
|
|
|
}
|
|
|
|
|
2020-06-24 15:11:10 +00:00
|
|
|
/**
|
|
|
|
* @internal
|
|
|
|
*/
|
2020-05-07 10:54:55 +00:00
|
|
|
async _adoptElementHandle(
|
|
|
|
elementHandle: ElementHandle
|
|
|
|
): Promise<ElementHandle> {
|
|
|
|
assert(
|
|
|
|
elementHandle.executionContext() !== this,
|
|
|
|
'Cannot adopt handle that already belongs to this execution context'
|
|
|
|
);
|
2019-01-28 20:24:27 +00:00
|
|
|
assert(this._world, 'Cannot adopt handle without DOMWorld');
|
|
|
|
const nodeInfo = await this._client.send('DOM.describeNode', {
|
|
|
|
objectId: elementHandle._remoteObject.objectId,
|
|
|
|
});
|
2020-01-27 13:44:53 +00:00
|
|
|
return this._adoptBackendNodeId(nodeInfo.node.backendNodeId);
|
2019-01-28 20:24:27 +00:00
|
|
|
}
|
2017-10-06 22:35:02 +00:00
|
|
|
}
|