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.
|
|
|
|
*/
|
|
|
|
|
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
|
|
|
import {helper, assert} from './helper';
|
|
|
|
import {createJSHandle, JSHandle, ElementHandle} from './JSHandle';
|
|
|
|
import {CDPSession} from './Connection';
|
2020-04-28 16:45:55 +00:00
|
|
|
import {DOMWorld} from './DOMWorld';
|
2020-04-29 11:28:16 +00:00
|
|
|
import {Frame} from './FrameManager';
|
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;
|
|
|
|
|
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 {
|
|
|
|
_client: CDPSession;
|
2020-04-28 16:45:55 +00:00
|
|
|
_world: DOMWorld;
|
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
|
|
|
_contextId: number;
|
|
|
|
|
2020-04-28 16:45: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;
|
2017-10-06 22:35:02 +00:00
|
|
|
}
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
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 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
|
|
|
}
|
|
|
|
|
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 evaluateHandle(pageFunction: Function | string, ...args: unknown[]): Promise<JSHandle> {
|
|
|
|
return this._evaluateInternal<JSHandle>(false, pageFunction, ...args);
|
2019-06-07 20:46:43 +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
|
|
|
private async _evaluateInternal<ReturnType>(returnByValue, 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;
|
2018-07-12 01:38:34 +00:00
|
|
|
const expressionWithSourceUrl = SOURCE_URL_REGEX.test(expression) ? expression : expression + '\n' + suffix;
|
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
|
|
|
|
2018-06-14 22:27:59 +00:00
|
|
|
const {exceptionDetails, result: remoteObject} = await this._client.send('Runtime.evaluate', {
|
2018-07-12 01:38:34 +00:00
|
|
|
expression: expressionWithSourceUrl,
|
2018-05-04 18:45:16 +00:00
|
|
|
contextId,
|
2019-06-07 20:46:43 +00:00
|
|
|
returnByValue,
|
2018-05-04 18:45:16 +00:00
|
|
|
awaitPromise: true,
|
|
|
|
userGesture: true
|
2018-06-14 22:27:59 +00:00
|
|
|
}).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)
|
|
|
|
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
|
|
|
|
2019-06-07 20:46:43 +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')
|
2019-02-14 07:41:53 +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 '))
|
|
|
|
functionText = 'async function ' + functionText.substring('async '.length);
|
|
|
|
else
|
|
|
|
functionText = 'function ' + functionText;
|
|
|
|
try {
|
|
|
|
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,
|
|
|
|
userGesture: true
|
|
|
|
});
|
2020-04-28 13:16:28 +00:00
|
|
|
} catch (error) {
|
|
|
|
if (error instanceof TypeError && error.message.startsWith('Converting circular structure to JSON'))
|
|
|
|
error.message += ' Are you passing a nested JSHandle?';
|
|
|
|
throw error;
|
2019-01-14 22:30:50 +00:00
|
|
|
}
|
2020-04-21 09:40:04 +00:00
|
|
|
const {exceptionDetails, result: remoteObject} = await callFunctionOnPromise.catch(rewriteError);
|
2017-10-06 22:35:02 +00:00
|
|
|
if (exceptionDetails)
|
|
|
|
throw new Error('Evaluation failed: ' + helper.getExceptionMessage(exceptionDetails));
|
2019-06-07 20:46:43 +00:00
|
|
|
return returnByValue ? helper.valueFromRemoteObject(remoteObject) : createJSHandle(this, remoteObject);
|
2017-10-06 22:35:02 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @param {*} arg
|
|
|
|
* @return {*}
|
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 {
|
2019-03-15 17:20:48 +00:00
|
|
|
if (typeof arg === 'bigint') // eslint-disable-line valid-typeof
|
2020-04-21 09:40:04 +00:00
|
|
|
return {unserializableValue: `${arg.toString()}n`};
|
2017-10-06 22:35:02 +00:00
|
|
|
if (Object.is(arg, -0))
|
2020-04-21 09:40:04 +00:00
|
|
|
return {unserializableValue: '-0'};
|
2017-10-06 22:35:02 +00:00
|
|
|
if (Object.is(arg, Infinity))
|
2020-04-21 09:40:04 +00:00
|
|
|
return {unserializableValue: 'Infinity'};
|
2017-10-06 22:35:02 +00:00
|
|
|
if (Object.is(arg, -Infinity))
|
2020-04-21 09:40:04 +00:00
|
|
|
return {unserializableValue: '-Infinity'};
|
2017-10-06 22:35:02 +00:00
|
|
|
if (Object.is(arg, NaN))
|
2020-04-21 09:40:04 +00:00
|
|
|
return {unserializableValue: 'NaN'};
|
2017-10-06 22:35:02 +00:00
|
|
|
const objectHandle = arg && (arg instanceof JSHandle) ? arg : null;
|
|
|
|
if (objectHandle) {
|
|
|
|
if (objectHandle._context !== this)
|
|
|
|
throw new Error('JSHandles can be evaluated only in the context they were created!');
|
|
|
|
if (objectHandle._disposed)
|
|
|
|
throw new Error('JSHandle is disposed!');
|
|
|
|
if (objectHandle._remoteObject.unserializableValue)
|
2020-04-21 09:40:04 +00:00
|
|
|
return {unserializableValue: objectHandle._remoteObject.unserializableValue};
|
2017-10-06 22:35:02 +00:00
|
|
|
if (!objectHandle._remoteObject.objectId)
|
2020-04-21 09:40:04 +00:00
|
|
|
return {value: objectHandle._remoteObject.value};
|
|
|
|
return {objectId: objectHandle._remoteObject.objectId};
|
2017-10-06 22:35:02 +00:00
|
|
|
}
|
2020-04-21 09:40:04 +00:00
|
|
|
return {value: arg};
|
2017-10-06 22:35:02 +00:00
|
|
|
}
|
2018-06-14 22:27:59 +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 rewriteError(error: Error): Protocol.Runtime.evaluateReturnValue {
|
2019-06-11 00:35:40 +00:00
|
|
|
if (error.message.includes('Object reference chain is too long'))
|
|
|
|
return {result: {type: 'undefined'}};
|
|
|
|
if (error.message.includes('Object couldn\'t be returned by value'))
|
|
|
|
return {result: {type: 'undefined'}};
|
|
|
|
|
2019-10-23 09:41:01 +00:00
|
|
|
if (error.message.endsWith('Cannot find context with specified id') || error.message.endsWith('Inspected target navigated or closed'))
|
2018-06-14 22:27:59 +00:00
|
|
|
throw new Error('Execution context was destroyed, most likely because of a navigation.');
|
|
|
|
throw error;
|
|
|
|
}
|
2017-10-06 22:35:02 +00:00
|
|
|
}
|
2017-10-11 21:41:20 +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
|
|
|
async queryObjects(prototypeHandle: JSHandle): Promise<JSHandle> {
|
2018-05-31 23:53:51 +00:00
|
|
|
assert(!prototypeHandle._disposed, 'Prototype JSHandle is disposed!');
|
|
|
|
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', {
|
|
|
|
prototypeObjectId: prototypeHandle._remoteObject.objectId
|
|
|
|
});
|
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
|
|
|
|
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 _adoptBackendNodeId(backendNodeId: Protocol.DOM.BackendNodeId): Promise<ElementHandle> {
|
2020-01-27 13:44:53 +00:00
|
|
|
const {object} = await this._client.send('DOM.resolveNode', {
|
|
|
|
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
|
|
|
}
|
|
|
|
|
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 _adoptElementHandle(elementHandle: ElementHandle): Promise<ElementHandle> {
|
2019-01-28 20:24:27 +00:00
|
|
|
assert(elementHandle.executionContext() !== this, 'Cannot adopt handle that already belongs to this execution context');
|
|
|
|
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
|
|
|
}
|