Documentation Bug: platformName must be lowecase windows

[htho]

All documentation and error messages for platformName mention the windows platform in Titlecase: Windows. But the driver only accepts windows as lowercase: windows.

This took me a day to figure out.

These are the steps to reproduce from my Stackoverflow question:

I want to run tests on a remote Windows 10 machine.
The machine has Chrome installed.

I installed Appium and the chromium driver in a simple npm package on that machine.

package.json

{
  "dependencies": {
    "appium": "^2.5.1",
    "appium-chromium-driver": "^1.3.20"
  },
  "scripts": {
    "start": "appium --allow-cors"
  }
}

then I start Appium like this:

npm run start

I Test the Server locally using the Appium Inspector (https://inspector.appiumpro.com/):

Remote Host: 127.0.0.1
Remote Port: 4723
Remote Path: /

{
  "platformName": "Windows",
  "browserName": "chrome",
  "appium:automationName": "Chromium"
}

When I click Start Session, I get this Error:

Failed to create session. An unknown server-side error occurred while processing the command. Original error: A new session could not be created. Details: session not created: No matching capabilities found

[jlipps]

This is due to a recent breaking change in Chromedriver itself, which this project is merely a thin interface for. Any help in fixing casing issues in docs/examples via PRs would be very much appreciated!

[bengeorge]

Linux needs to be linux

macOS needs to be mac

(whilst I understand the issue isn't in this project, I am mentioning here as it is the "interface" into Chromedriver for many)

[jlipps]

Thank you! Would you like to submit a PR with these updates to the documentation?

[bengeorge]

Sure can. Can I push a branch to this repo ?

Do you know where the actual docs are for the Chromedriver releases ?

[jlipps]

The process for opening a PR on an open source repo is to first fork the repo, push to your fork, and then create a PR. you can also simply navigate to the file where you want to make a change, and propose a PR from the github UI itself (which is easiest for docs changes like this). I'm not sure where you'd want to update the docs exactly, presumably wherever you saw the (now-)erroneous examples that led you to create this issue?