Expand upon the browser capabilities mechanism

[craigfowler]

I have a mechanism for describing the capabilities of web browsers and then detecting those capabilities within test code (particularly actions).

Unfortunately browser and OS versions and their behaviours presents us with a moving target and so this mechanism needs to be expanded upon.

Desired features of new system

• Cheap to develop and ship As new versions are released and capabilities change, it needs to be cheap to update and release a new version
• Cheap to read and understand It should be easy for a developer with only limited skill to open and edit and understand browser capabilities.
• Avoid needing updates when nothing changes The mechanism of mapping browser versions to capabilities should only need updating when something changes. There should be a concept of 'latest' version and if there is no chance between two latest versions then the info does not need changing.
• Easy for developers to override locally with their own info Even though new capabilities into can be shipped quickly, it must be possible for developers to override the shipped info which their own. This allows them to quickly patch in their own workarounds or updates before they are centrally available.

Proposed solution

Use a text-based tabular format like CSV for the browser capabilities. This would be a matrix of version numbers and the capabilities showing which apply to which.

Each browser and OS combination gets a single text file. Each file would be compiled into an assembly which can then be shipped as a NuGet package. This would be frequently re-released with updates.

When a file has an OS then that is used. Also an earlier OS version may be used as a fallback. Finally a non-versioned OS version of the file may also be used.

We need a separate OS file which lists the operating system versions and how they relate to one another:

• Is an OS name a parent of another (a parent is a general name for that same operating system, like Windows is a parent of Windows 10)
• Is a version earlier than another or later than the other

[craigfowler]

Another solution to consider is a JSON-based format.

Something like:

• Browser name
• Operating system name
• Min OS version
• Max OS version
• Min Browser version
• Max Browser version
• Collection of browser capabilities/flags

These can still be compiled in as resources but could be overridden by ones supplied from the consuming code.

[craigfowler]

This is very closely related to this related issue in the WebDriverExtras repository. In that issue I'll be creating a provider that is able to receive an object model of web driver flags. That object model will have the shape described in this ticket.

[craigfowler]

Migrated