C# Bindings generating invalid W3C request.

[pulkitsharma07]

Start request generated from the following code snippet (Using C# binding version 3.11.0) contains keys outside the W3C spec.

 IWebDriver driver;
 FirefoxOptions firefoxOptions = new FirefoxOptions();
 DesiredCapabilities capability = (DesiredCapabilities)firefoxOptions.ToCapabilities();
 capability.SetCapability("browserstack.selenium_version", "3.10.1");
 capability.SetCapability("version", "50");

 driver = new RemoteWebDriver(new Uri("http://localhost:8082/wd/hub"), capability);

Expected Behavior -

{
  "desiredCapabilities": {
    "browserName": "firefox",
    "moz:firefoxOptions": {
    },
    "browserstack.selenium_version": "3.10.1",
    "version": "50"
  },
  "capabilities": {
    "firstMatch": [
      {
        "browserName": "firefox",
        "moz:firefoxOptions": {
        }
      }
    ]
  }
}

Actual Behavior -

{
  "desiredCapabilities": {
    "browserName": "firefox",
    "moz:firefoxOptions": {
    },
    "browserstack.selenium_version": "3.10.1",
    "version": "50"
  },
  "capabilities": {
    "firstMatch": [
      {
        "browserName": "firefox",
        "moz:firefoxOptions": {
        },
        "browserstack.selenium_version": "3.10.1"
      }
    ]
  }
}

version (and platform) do not get mapped into the W3C capabilities because they are being blacklisted here

selenium/dotnet/src/webdriver/Remote/RemoteWebDriver.cs

Line 1161 in ebd897a

if (entry.Key != CapabilityType.Version && entry.Key != CapabilityType.Platform)

.

Please correct me if I am missing something obvious. Thanks.

[jimevans]

The challenge is that it’s impossible for the bindings to tell when a capability added directly to DesiredCapabilities should legitimately be added to only the non-W3C portion of the capabilities JSON blob, or whether it should also be part of the W3C capabilities as well. If BrowserStack (and other third-party/cloud providers) made their additional service-specific options compatible with the specification, this wouldn’t be an issue. I acknowledge the payload being generated by the bindings isn’t spec-compatible, but I also don’t see a clear, elegant way to fix it.

[pulkitsharma07]

I understand that we need to migrate our capabilities to ensure that they follow the W3C specification (for example vendor prefix them in the correct way).

But while we get there, Can the bindings maintain a set of keys which are W3C spec compliant and map only those to W3C caps ? I think other bindings also follow a similar approach.

[jimevans]

Could they? Sure. Should they? That’s a conversation worth having. I wouldn’t be opposed to using this as a forcing function to encourage third-party/cloud providers to re-evaluate the current priority they’ve placed on spec-compliance. In my discussions with product teams there, the attitude has almost universally been, “We’ll get to it when we have time, but we have so many other things of higher priority.” In my experience, nothing increases priority faster than, “Your users won’t be able to use your service anymore unless you make this change.”

Of course, I’m not seriously considering making that a reality. I’ll see what I can do about making changes. Please note that it’ll likely be on the order of weeks before I have time to do so, or even to review a PR if one were forthcoming.

Also, please be aware that I’m unhappy about having to fix this “bug” (scare quotes intentional). It’s frustrating that I’ve been banging this drum for cloud providers to make these updates for literally a solid year. In addition to speaking privately with engineering teams at several providers, I’ve spoken about it publicly too,including keynote addresses talking about it at industry conferences, at which I am quite certain representatives of cloud providers were in attendance.

[jimevans]

I've "fixed" this in 6103798. Going forward, @pulkitsharma07, you should be encouraging your .NET users to avoid DesiredCapabilities altogether. The appropriate JSON payload can be created without converting to DesiredCapabilities at all. To wit:

// Note the "true" argument on the calls to AddAdditionalCapability. This tells
// the bindings that the additional capability should be added to the top-level
// of the dictionary, and not inside the browser-specific ('moz:firefoxOptions')
// JSON object.
FirefoxOptions firefoxOptions = new FirefoxOptions();
firefoxOptions.AddAdditionalCapability("browserstack.selenium_version", "3.10.1", true);
firefoxOptions.AddAdditionalCapability("version", "50", true);

IWebDriver driver = new RemoteWebDriver(new Uri("http://localhost:8082/wd/hub"), firefoxOptions);