[browser-logs] print promises

Promises logged to the console show up as {}.

We can improve that, at the least we can print Promise { } . If possible it would be great to mirror the behavior of the browser/node terminal to also log the Promise status and/or result. I’m not sure if it’s possible to get this status synchronously from the promise object.

[LarsDenBakker]

@43081j thanks for the explanation, it’s spot on.

I think for the first version we can start with a compromise - just return "Promise { }". I don’t know of any way to synchronously check if a promise is already resolved… maybe someone knows a trick but we can also add this later. The most important part is communicating that it actually is a promise so that people can know how to proceed with debugging.

[43081j]

@ashikvarma11 if you want to pick this up here’s my suggested solution:

The browser-logs code really seems to exist so it can copy a logged value (via console.log) from the browser session to the test runner:

• Catch all logs
• Serialise each logged value to a string (using serialize)
• Pass the string back to the test runner (through playwright/puppeteer or whatever is used)
• Deserialise the string back to a “fake” object which represents the original one (using deserialize)

So if you want to print promises nicely, you need to change the serialiser to return something like:

{ [KEY_WTR_TYPE]: 'Promise' }

Just like undefined is handled here.

Unfortunately im not aware of a way to check if a promise has resolved or rejected without actually asynchronously catching/then-ing it (which we can’t do here because a JSON reviver is synchronous).

Then in the deserialiser you need to add a case to set a fake promise (or something representing one). Just like the one for functions here:

case 'Promise':
  return new Promise((res) => { /* implementation hidden */ });

it’s not great to be generating loads of unresolved promises i suppose. You could also return a Promise.resolve() but that may be misleading if what was originally serialised was a rejected promise.

Maybe @LarsDenBakker would be happy with some compromise where we don’t make a real promise but just log a string representing one instead, i’m not sure.