imiric
commented
2 years ago Thanks for opening this issue @mtarancon!
I took a look at it and it's not a problem with WebGL or any site for that matter, but with our waitForFunction() implementation. Here's a minimal script that reproduces the panic:
import launcher from 'k6/x/browser';
export default function() {
const browser = launcher.launch('chromium', {
headless: true,
});
const context = browser.newContext();
const page = context.newPage();
page.waitForFunction(() => true);
page.close();
browser.close();
}This happens on current main (990a95c).
There are several issues here though... :disappointed: Some notes for developers:
-
The nil pointer panic happens because of the way we're passing the last argument to
ExecutionContext.eval()here:argsis[]goja.Value{goja.Value(nil)}(i.e. has one nilgoja.Value), which is why the nil panic happens inconvertArgument().This is simple enough to fix, but doing that exposes another bigger problem...
-
Currently
ExecutionContext.eval()expects[]goja.Valueas arguments, for which it then callsconvertArgument()on. The issue with this is thatconvertArgument()currently only handles primitive serializable and unserializable values.Since the first argument to
injected.waitForPredicateFunction()must be a function, and it's currently passed viaCallArgument.Valueas a string, the eval fails withTypeError: predicate is not a function.The way to fix this is to first evaluate the predicate function, get its object ID, and pass it as
CallArgument.ObjectIDinstead. This will require changingFrame.waitForFunction,ExecutionContext.evaland possiblyconvertArgument, so it's not trivial.
Given that the first problem masks the second one, let's use this issue for tracking both bugs.
Thanks again for reporting this @mtarancon. We'll try to get this fixed in the upcoming v0.3.0 release (end of this month). :crossed_fingers:
In the meantime, could you write the test without using waitForFunction()? Maybe use waitForSelector() and then evaluate() if you need to interact with the WebGL object?
The good news is that this is not related to WebGL :tada: I tested with this demo, and it worked without issues on my machine (ran at 60FPS).
Hi, I am trying to make the xk6-browser work for an application that has WebGL unity application, unfortunately I cant share the webGL because its still a WIP bur I want to test it with your amazing tool, I am having this issue:
Im using MacOS Catalina 10.15.7