Bug 182065 – Web Inspector: Include an inspector protocol version number

• Component: Web Inspector
• Status: NEW

[Joseph Pecoraro]

Include an inspector protocol version number

It is possible that the backend can change the values it sends, but the protocol itself stays the same. In order to detect such changes, and react to them in the frontend, there would need to be something that could be checked.

• So far we've been relying on "check for something else in the protocol changing and use that as an indicator" but that is not always perfect.
• We've also done "check the value and change behavior based on the type / appearance of the value" but that is not always perfect.

Adding a version number to the protocol would make this simpler, we could just check against the version number.

[Joseph Pecoraro]

Created attachment 332201 [details]
[PATCH] iOS Version Number Approach

I can see a few possible approaches.

1. Give a version number to iOS backend commands targets

    From:

        Source/WebInspectorUI/Versions/Inspector-iOS-9.3.json

    We can generate a version number:

        InspectorBackend.version = 9.3;

    Drawbacks:
    - These version numbers are not linear with time.
    - What if we have non-iOS targets, their version numbers wouldn't map the same.
    - Requires a default value of something like Infinity

2. Bump a version number whenever we need it.

    This could be a:

        Source/JavaScriptCore/inspector/protocol/version.txt

    That contains a number:

        1234

    We would include this in the Combined.json:

        { "version: 1234, "domains": [...] }

    We can generate a version number:

        InspectorBackend.version = 1234;

    Drawbacks:
    - When do we decide to bump the version number? Any protocol change? As needed?

---

This attachment implemented (1) just to see what it would be like.
I think (2) is real way to go.

[Blaze Burg]

I don't like the iOS version approach. It doesn't work for Automation protocol, or make sense for other ports or other platforms that run JSContext.

The most simple thing to do is to increment a number whenever the protocol changes. It would be easiest to maintain this in a separate file rather than trying to extract it from domain JSON files.

A more sophisticated approach would be something like SemVer (https://semver.org). This would allow us to warn downstream projects whenever we make a backwards-incompatible change (changing required arguments, deleting anything). Most changes do not affect backwards compatibility. We can then gate relevant code paths on a major or minor version number depending on the need.