Make Chrome values consistent inapi/Body.json.

[jpmedley]

Here's the line that shows arrayBuffer is in WebView: https://cs.chromium.org/chromium/src/android_webview/tools/system_webview_shell/test/data/webexposed/global-interface-listing-expected.txt?g=0&l=4701

[queengooborg]

Thanks for your PR. So, the Body API wasn’t implemented behind the Experimental Web Features flag in Chrome 41, it was just introduced in Chrome 42?

[jpmedley]

It may have been, but Chrome experimental flags are not part of the web platform and I have been asked (by the people who pay my salary) not to submit them to BCD.

[jpmedley]

I should clarify.

• Under no circumstance should a user ever be told to toggle a Chrome flag to use a website.
• The flag was intended for web developers to experiment with. If the feature is available in stable Chrome, that's what developers should be experimenting with. To experiment with the flagged feature is to experiment with code that will never be updated and is not available to users.

[ddbeck]

@jpmedley would you be willing to open a PR documenting a Chrome flags policy? data-guidelines.md would be a good place for it.

At first glance, I think I'm OK with the idea of dropping flag data for features which have shipped generally in Chrome. But I'd prefer to give it room for discussion and explicitly document the practice, rather than doing it on an ad hoc basis. I understand that you don't plan to submit Chrome experimental flag data, but removing seemingly valid data from BCD seems like a step further, which merits discussion and documentation.

[jpmedley]

If you want to leave in the flag information, then who do you think would need it?

[ddbeck]

If you want to leave in the flag information, then who do you think would need it?

I'm not sure I follow this question. It's your PR—I'm not the one proposing any changes here.

I'll grant that the data lost here is unlikely to be actionable for web developers. But "who cares?" isn't a standard I usually apply to reviewing PRs. Normally, I ask contributors to justify their work, to show some evidence that the changes in a PR are accurate and follow the documented guidelines. This PR is a bit odd because the data removal isn't part of our usual practices and there's no claim about the accuracy of the removed data.

[queengooborg]

Marking this as "inactive" since there hasn't really been any additional discussion on this, and I haven't seen an issue about a Chrome flag policy.

[jpmedley]

@ddbeck Let me rephrase then. After a feature ships by default in Chrome there's nobody who should be flipping a runtime flag. Any user who wants to kick a feature's tires should do so in the production version. So, what reason would anyone have for using a version of Chrome with a runtime flag after the flag's feature ships enabled by default.

If someone were to submit a bug ticket on a flagged feature, they would be asked to try it in the current stable version. If it works in the current stable version, the ticket will be marked "Won't fix."

This is all a long way of saying defuct flag information is for all practical purposes unusable by web developers. As such, it only adds weight to the JSON files. Am I missing another scenario where it might be useful?

[ddbeck]

@jpmedley I don't support removing dead flag data on an ad-hoc basis. There's two different issues here that I think are getting mixed up so I'm going to try to spell this out more clearly.

If you just want to get this PR merged, without doing any other work on the broader question of handling dead flags, here's what I'd accept. You can either mark the old flag as dead (my preference, see #3318 (comment) for details), like this:

          "chrome": [
            {
              "version_added": "42"
            },
            {
              "version_added": "41",
              "version_removed: "42",
              "flags": [
                {
                  "type": "preference",
                  "name": "Experimental Web Platform Features"
                }
              ]
            }
          ],

Or you can leave the historic data untouched, like this:

          "chrome": [
            {
              "version_added": "42"
            },
            {
              "version_added": "41",
              "flags": [
                {
                  "type": "preference",
                  "name": "Experimental Web Platform Features"
                }
              ]
            }
          ],

If you want to wholly remove the flag data, then you'll have to deal with that in a separate a PR. There are two plausible routes I see for that happening:

• For piecemeal removal of Chrome flag data, as you've done in the current diff: open a PR updating the contribution guidelines to document a policy for when to remove dead flag data.

  Piecemeal removal has challenges, which you would have to address. I would suggest re-reading all of Choose and document a policy for flagged features  #3318 before opening such a PR. That issue describes an all-browsers approach to which no one really objected (and one that I suggested for resolving this PR, in my first code block), though I never really followed through on the documentation part

• For bulk removal of Chrome flag data and/or banning it outright through a schema change, follow the migrations process.

[queengooborg]

Hey @jpmedley, how do you want to proceed with this? Do you want to mark the flag as dead, or are you leaning towards removal of all Chrome flag data and want to get that going in a separate issue?

[Elchi3]

Given no answer from @jpmedley here, I'm closing this PR as there is no policy to follow and piecemeal removals are not worth reviewer's time. Please come back with an answer to the policy questions and we may move forward this again.