I think the best way is to split this into 2 or 3 steps depending on how safe we want to play it. I suggest we go with 3 since we will be able to revert if things don't look good. Steps:
1) Fold types into each other in the test-results UI to gauge user response. This is revertable.
2) Fold types into each other on upload so json is stored with new statuses.
3) Change clients to upload simplified types.

Excellent--

Also, remember that if people still want to keep showing more detail on the test-results UI but we still want to simplify the test result types, we could add additional fields to the per-test results dict to specify what type of mismatch there was.

This could parallel the current optional fields that we have now called "is_missing_audio", "is_missing_text", "is_missing_video", which add more detail for the single test result "MISSING".

So for example, we could theoretically make it so that layout test results look like this:

    "tests": {
        "foo": {
            "bar": {
                "test-a.html": {
                    "expected": "PASS",
                    "actual": "MISSING",
                    "is_unexpected": true,
                    "is_missing_audio": true
                },
                "test-b.html": {
                    "expected": "FAIL",
                    "actual": "PASS",
                    "is_unexpected": true
                },
                "test-c.html": {
                    "expected": "PASS",
                    "actual": "FAIL",
                    "is_unexpected": true,
                    "is_text_mismatch": true,
                    "is_video_mismatch": true
                } 
            }
        }
    }

IF the goal of this change is to simplify the list of test result types, but not necessarily to simplify the test-results UI, then this might be a reasonable option. What do you think?

Part of the motivation for the removal of application-specific statuses is to simplify the dashboard UI code and the concepts we expose to users viewing test history, so ideally we wouldn't just be moving the source of custom stuff to different fields.

This is something we can revisit later, though. It should be solved in a way that would allow other teams to have their own custom statuses if we do.

Remaining work on this bug is:
2) Fold types into each other on upload so json is stored with new statuses.
3) Change clients to upload simplified types.

Making available for now since I likely won't work on this for a while.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot