How to use ShouldContainRefererHeader method of PuppeteerSharp.Tests.RequestInterceptionTests.SetRequestInterceptionTests class

For anybody still encountering this issue, the answer by jamie-tillman on this github issue solved it for me:

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
#####################
#PUPPETEER RECIPE based on https://github.com/hardkoded/puppeteer-sharp/issues/1180#issuecomment-1015532968
#####################
RUN apt-get update && apt-get -f install && apt-get -y install wget gnupg2 apt-utils
RUN wget -q -O - https://dl.google.com/linux/linux_signing_key.pub | apt-key add -
RUN echo 'deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main' >> /etc/apt/sources.list
RUN apt-get update \
&& apt-get install -y google-chrome-stable --no-install-recommends --allow-downgrades fonts-ipafont-gothic fonts-wqy-zenhei fonts-thai-tlwg fonts-kacst fonts-freefont-ttf
######################
#END PUPPETEER RECIPE
######################
ENV PUPPETEER_EXECUTABLE_PATH "/usr/bin/google-chrome-stable"
WORKDIR /app
EXPOSE 80
EXPOSE 443

The path to the executable is automatically detected by Puppeteer. However, I still had to disable sandboxmode as seen in the snippet below:

var browser = await Puppeteer.LaunchAsync(new LaunchOptions
{
    Headless = true,
    Args = new [] {
      "--disable-gpu",
      "--disable-dev-shm-usage",
      "--disable-setuid-sandbox",
      "--no-sandbox"}
});

More useful information is found in the issue thread so I recommend skimming through it if you still have trouble.

I have found the solution, here it is for those who may be interested:

First, we should create a CDPSession like this:

var client = await page.Target.CreateCDPSessionAsync();

then we should Evaluate our script to get an element:

var body = await client.SendAsync("Runtime.evaluate", new { expression = "document.getElementsByTagName('input')[0]" });

and at last, we should use DOMDebugger with the element's objectId to get its event listeners:

var result = await client.SendAsync("DOMDebugger.getEventListeners", new { objectId = body["result"]["objectId"] });

Technically speaking this a missing feature on the Linq methods. It's not so simple to code Async Linq functions.

On the other side, I find this much more simple to implement straight in javascript. Why? because you can test your script in your browser and then just move it to your C# code.

For instance, this method will find all li elements, find the li with a span with the text fire and then click the input.

await page.EvaluateFunctionAsync(@"() => {
     Array.from(document.querySelectorAll('li'))
         .find(l => l.querySelector('span').innerText === 'fire').querySelector('INPUT').click();
}");

Try adding the URL/Domain to Internet Download Manager's exception list. It will ignore the download request.

You can use Page.WaitForFileChooserAsync to interact with the file chooser. The important thing to remember is you need to have the file chooser ready before you click the <input type="file">.

For example:

var fileChooserDialogTask = page.WaitForFileChooserAsync(); // Do not await here

await Task.WhenAll(fileChooserDialogTask, page.ClickAsync("input[type='file']"));

var fileChooser = await fileChooserDialogTask;
await fileChooser.AcceptAsync(pathToFile);

If you try to click the <input type="file"> before you've called WaitForFileChooserAsync, you'll be stuck with the modal file chooser dialog waiting for you to do something.

using below,

using var page = browser.NewPageAsync().Result;

page.TypeAsync("input[name='elementname']", valuetobeset).Wait();

You don't need to call Dispose if you call CloseAsync. Dispose is just a fire and forget call to CloseAsync. See.

You are on the wrong direction. The referenced site has playlist api which returns json. you can get information from :

http://iloveradio.de/typo3conf/ext/ep_channel/Scripts/playlist.php

Edit: Chome Inspector is used to find out Playlist link

I think you should not do a .ConfigureAwait on the controller level, look at this article for more information: https://blog.stephencleary.com/2017/03/aspnetcore-synchronization-context.html.

ASP.NET team dropped the use of SynchronizationContext, so using it in your controller is pointless.

As the article states, you should still use it on your service level, as you don't know whether or not a UI could plug itself to the service and use it, but on your WEB API, you can drop it.