fix: safely parse AppiumDriver.Location response

[Dor-bl]

Related issue

Closes # n/a

List of changes

• AppiumDriver.Location getter no longer throws NullReferenceException / KeyNotFoundException when the server returns a non-dictionary payload or omits altitude / latitude / longitude.
• Values are read with TryGetValue and converted via a TryConvertToDouble helper (CultureInfo.InvariantCulture); missing, null or non-numeric values fall back to 0.0.
• Adds AppiumDriverLocationTests (mocked command executor, no device needed) covering numeric, integer/string, missing-key, null, non-numeric, non-convertible, non-dictionary and null-response payloads.

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change that adds functionality or value)
• Refactoring (non-breaking change that improves code without altering functionality)
• Breaking change (fix or feature that would cause existing functionality not to work as expected)
• New test coverage (non-breaking change that adds tests for existing, previously untested functionality)
• Test fix (non-breaking change that improves test stability or correctness)
• Chore/Maintenance (updates to build scripts, dependencies, or GitHub Actions)

Tests

• Unit tests
• Integration tests
• No automated tests (explain why below)

How they run: dotnet test test/integration/Appium.Net.Integration.Tests.csproj --filter "FullyQualifiedName~AppiumDriverLocationTests" (8 tests, no device required, no CI changes needed).

Documentation

• Have you proposed a file change/PR with Appium to update documentation?
• Not applicable (no user-facing behaviour change, e.g. tests, CI or maintenance only)

Details

Replaces Dor-bl#244, which had drifted from main and carried unrelated changes.

[Copilot]

Copilot review overview

🟡 Changes recommended

Narrow exception handling to avoid suppressing unrelated critical failures.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1

Open (1)

• Avoid catch-all exception handling during coordinate conversion · New

What changed in this PR

This pull request hardens AppiumDriver.Location parsing for malformed or incomplete server responses and adds mocked test coverage.

Changes:

• Adds invariant-culture coordinate conversion with safe fallbacks.
• Handles missing, null, non-numeric, and non-dictionary responses.
• Adds comprehensive location parsing tests.

File	Description
test/​integration/​Driver/​AppiumDriverLocationTests.cs	Tests valid and malformed location payloads.
src/​Appium.Net/​Appium/​AppiumDriver.cs	Updates location parsing and conversion behavior.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Copilot review overview

🔵 Needs a closer look

Boolean payloads must be rejected before conversion, with regression coverage added.

Review effort: Lite
Findings: None

Resolved since last review (1)

• Avoid catch-all exception handling during coordinate conversion

Previously missed (1)

In code that hasn't changed since last review

Reject boolean JSON values before coordinate conversion

src/​Appium.Net/​Appium/​AppiumDriver.cs:332

Convert.ToDouble treats JSON booleans as numeric (true becomes 1.0), so a malformed payload such as { "latitude": true } bypasses the documented 0.0 fallback and returns an invalid coordinate. Reject booleans before conversion and add a regression case for this server response.

[Copilot]

Copilot review overview

🔵 Needs a closer look

Reject boolean and non-finite coordinate values and add regression coverage.

Review effort: Lite
Findings: None

[Copilot]

Copilot review overview

🔵 Needs a closer look

Boolean coordinate values must be rejected instead of being converted to 1.0.

Review effort: Lite
Findings: None

Previously missed (1)

In code that hasn't changed since last review

Reject Boolean values before converting coordinates to double

src/​Appium.Net/​Appium/​AppiumDriver.cs:335

Convert.ToDouble(object, ...) treats a Boolean as a numeric value (true becomes 1.0), so a valid JSON boolean coordinate would return 1.0 instead of the documented fallback of 0.0 for non-numeric values. Reject Boolean values before conversion (and add a regression case) so malformed server payloads cannot produce a coordinate of one.