2.1.1 regression: allowedOrigins value "null" is not a valid origin

[dbjorge]

Describe the bug

Our sample project using this library began seeing a failure in previously-working usage with 2.1.1. The symptom reported by the test runner is:

An exception of type 'Microsoft.VisualStudio.TestTools.UnitTesting.AssertFailedException' occurred in FluentAssertions.dll but was not handled in user code: 'Expected axeResultExcludingExampleViolationsElement.Violations to be empty, but found <null>.'

Running under a debugger, the real issue proves to be that axe-core has returned an error, so the AxeResult object is the Error form with null data properties. The Error is allowedOrigins value "null" is not a valid origin.

I haven't debugged further than this yet. The error is surprising to see because SeleniumAxeDotnet doesn't explicitly override any axe-core configure() parameters, including allowedOrigins.

To Reproduce
Steps to reproduce the behavior:

1. Have .NET Core 3.1 installed
2. git clone https://github.com/microsoft/axe-pipelines-samples.git
3. cd axe-pipelines-samples/csharp-selenium-webdriver-sample
4. Update the Selenium.Axe reference in CSharpSeleniumWebdriverSample.csproj to version 2.1.1
5. dotnet test

Expected behavior
Analyze() produces an AxeResult successfully with data populated, as 2.1.0 does.

Screenshots
n/a

Desktop (please complete the following information):

• OS: Windows 21H1 OS Build 19043.985
• Browser: repros with firefox and chrome (latest respective drivers)
• Version: 2.1.1

[TroyWalshProf]

@dbjorge - Pretty sure this is not a Selenium Axe issue.
I think it is an Axe core issue.
If I use the Axe Chrome extension against the test page I get:

Workaround:
Add
chromeOptions.AddArguments("--disable-web-security");
when creating the Chrome driver

[TroyWalshProf]

Also, using the Accessibility Insights extension I get yelled at about setting Allow Access to file URLs.

Better workaround or legit fix:
chromeOptions.AddArgument("--allow-file-access-from-files");

[dbjorge]

On closer investigation, I agree that the issue definitely comes from axe-core and not SeleniumAxeDotnet (repros on the test page in question using axe-core directly).

I think this behavior does represent a bug, though; if a frame isn't communicable, axe-core should be reporting frame-tested violations, not throwing errors. Will file a new issue in axe-core.

[TroyWalshProf]

Ha, @dbjorge was just about to ping you about this one.
*This ticket was closed automatically as it was linked to #162; didn't want to just close without talking to you first.