`LaunchOptions.EnqueueAsyncMessages` docs suggest it's true by default while it isn't

[Androbin]

See the first line:

<summary>
Affects how responses to <see cref="CDPSession.SendAsync"/> are returned to the caller. If <c>true</c> (default), the
response is delivered to the caller on its own thread; otherwise, the response is delivered the same way <see cref="CDPSession.MessageReceived"/>
events are raised.
</summary>
<remarks>
This should normally be set to <c>true</c> to support applications that aren't <c>async</c> "all the way up"; i.e., the application
has legacy code that is not async which makes calls into PuppeteerSharp. If you experience issues, or your application is not mixed sync/async use, you
can set this to <c>false</c> (default).
</remarks>

public bool EnqueueAsyncMessages { get; set; }

[kblok]

It should be async all the way without this flag. Can you share an example?

[Androbin]

• EnqueueAsyncMessages is implicitly initialized to false.
• The first line of docs says "true (default)"
• The last line of docs says "false (default)"

[Androbin]

There is no other issue with the code, it's just this inconsistency in documentation.
Independent of that, I would personally like to vote for the default to be true.

[kblok]

Or you changed the description or I was thinking about another issue while writing that :p

The EnqueueAsyncMessages flag was created to support users using locking code. Which I don't think it's a good practice at all. I don't want to see Puppeteer# code with .Wait() or .Result after async calls.
The contributor back then implemented a feature, and I accepted it but under a flag turned off by default.

That's why my question back then was: 'is there any "good" code that needs this by default?'

[Androbin]

I ported puppeteer-extra-plugin-stealth to PuppeteerSharp (for a client). I am listening to Browser.TargetCreated and calling EvaluateOnNewDocumentAsync, which is supposed to run and finish executing before any other javascript can run on the page. Only with EnqueueAsyncMessages = true, everything works as expected. If you look at Javascripts event loop, this really is the implied behavior.

Here is a simplified version of the setup:

private async void PageCreateListener(object sender, TargetChangedArgs args)
{
    Target target = args.Target;

    if (target != null && target.Type == TargetType.Page)
    {
        Page page = await target.PageAsync();
        await page.EvaluateOnNewDocumentAsync("delete Object.getPrototypeOf(navigator).webdriver");
    }
}

var launchOptions = new LaunchOptions()
{
    EnqueueAsyncMessages = false,
    Headless = true,
};
await using Browser browser = await Puppeteer.LaunchAsync(launchOptions);
browser.TargetCreated += new EventHandler<TargetChangedArgs>(PageCreateListener);

await using Page page = browser.NewPageAsync();
await page.GoToAsync("https://bot.sannysoft.com/");
await page.WaitForTimeoutAsync(5000);

var screenshotOptions = new ScreenshotOptions
{
    FullPage = fullPage,
};
await page.ScreenshotAsync("testresult.png", screenshotOptions);

[Androbin]

Regardless of the desired default value, the documentation is inconsistent and that's a plain fact:
#1701 (comment)
https://github.com/hardkoded/puppeteer-sharp/blob/master/lib/PuppeteerSharp/LaunchOptions.cs#L178

[Androbin]

In the upstream Javascript code, async messages are enqueued implicitly due to language intrinsics.

[Androbin]

Another workaround if EnqueueAsyncMessages = false is to await the handler explicitly:

await using Page page = browser.NewPageAsync();
await page.EvaluateOnNewDocumentAsync("delete Object.getPrototypeOf(navigator).webdriver");
await page.GoToAsync("https://bot.sannysoft.com/");

[kblok]

In the upstream Javascript code, async messages are enqueued implicitly due to language intrinsic.

And that's why .NET is better :)
The thing is that you need those messages in queue. I might need speed, and process those messages as fast as I can.

But well, you are bringing one scenario that's good.

[kblok]

@Androbin I'm on the puppeteer's slack if you want to chat