BCD question: flag and "enabled by default in nightly only"

MDN
1

The Payment Request API has been available in part since Firefox 55, behind a preference. The API is now enabled by defaut on nightly builds only in Firefox 64. How do you write that in BCD?

Would this be the way to go?

"firefox": [
  {
    "version_added": "64",
    "notes": "Enabled by default in Nightly builds."
  },
  {
    "version_added": "55",
    "flags": [
      {
        "type": "preference",
        "name": "dom.payments.request.enabled",
        "value_to_set": "true"
      }
    ]
  }
],
2

Actually – does BCD care if it’s on by default or not? If not, then the addition isn’t needed at all.

3

I’d not bother with this. As far as web devs are concerned, it is still not available to use in production. afaik, we’ve not bothered with this kind of bcd for other APIs in a similar position. The only thing to change would be to make sure it is marked as enabled in nightly on the Experimental Features pages. We have an entry for Payment Request on there, but it currently states disabled and available since 55. You could change that to “Enabled (on since 64)”?

1 Like
4

Hm. OK. The problem I have is that it’s nice for BCD to indicate that 'hey, they’re working on it). :slight_smile:

5

I’ve been thinking about this some more. I increasingly think we need to have a way to indicate that support is available in special builds for experimentation purposes. Part of the point to having the documentation for these new technologies, especially ones still in development, is to encourage developers to experiment with them and hopefully provide feedback that will guide the API toward a better final state.

If the developer is not aware of browser support for the API, they will not feel that they even have the ability to try it out. We need to either move to including nightly-only stuff by including it as introduced in a given version but with a “Nightly only” note, or add a flag that can be set to indicate “preview builds only” in the BCD JSON. I am inclined to favor the latter. Especially if we pair it with adding a field to the browser JSON table that provides that browser’s name for their nightly/preview builds.

1 Like
6

IIRC, I put information like this into the notes field in my PRs which contributed Nightly‑only data.

7

We need to standardize this. And honestly, if the phrase “Available only in Nightly builds” is going to be used in notes all the time, why not save time and space and just have a flag for this concept?

Oh – another reason this matters: consider an API like Payment Request. This is an API which has been in CR status for several months now. Even though browsers are only just starting to move toward deploying it enabled by default, there are real-world web sites making use of this API. This is not the first and only API for which that’s been the case. Indeed, there have been highly experimental APIs which have been so well received that developers adopted them before the ink on the spec was dry.

For that reason, I think we need to be able to not only report that a feature was available as of a given release but only in preview builds, but also that it has been removed or changed as well, due to spec changes during the preview period. At least for APIs which have attained some degree of popularity ahead of being widely officially “shipped.”

1 Like
8

OK, these are reasonable arguments. So I guess your original snippet is probably OK in that case, at least for now, until we work out how else to represent this. Although I do still worry a bit that a small number of readers would find this interesting and useful, but a larger number might get confused or annoyed that we are reporting an API as supported, when it’s well, not really.

What flag would you propose for representing this?

1 Like
9

Yeah, the potential for confusion is why I’m starting really to like the idea of a “nightly/preview only” flag, or something similar.

So, the browsers/browsername.json files have records for each browser release that include a status field that can have one of a number of values, including exclusive, beta, nightly, etc.

How about we add an optional restriction or availability property to the version data in BCD that can take one of these values? This would let you indicate that a feature is only available in beta or later, nightly or later, or even that it’s only available in exclusive builds of some kind. Any special information beyond that can be included in a note.

That way, for these Payment Request items, I would then write it up in BCD like this:

"firefox": {
  "version_added": "55",
  "restriction": "nightly",
  "flags": [
    "type": "preference",
    "name": "dom.payments.enabled",
    "value_to_set": "true"
  ]
}

This describes a feature which is added in Firefox 55, but only for nightly builds, and that you also have to set dom.payments.enabled to true.

You can then similarly describe a feature added in Firefox 62 beta and nightly builds (the assumption being that beta would imply nightly as well; if we can’t make that assumption then we’d have to support an array here, which I think is probably overkill). The feature was then brought to general release in Firefox 64. No preference is required:

"firefox": [
  {
    "version_added": "64"
  },
  {
    "version_added": "62",
    "restriction": "beta"
  }
}

Then we can just add logic to the table building to look at the value of restriction and automatically add an appropriate annotation or note, or even to leave the table field empty except for a “see note” symbol that tells you it’s available only on nightly.

This lets us provide all the information in a clean way, and in a way that is easy to make fall back to pretending the feature doesn’t exist, just by looking for that restriction. If the restriction property is present, then the feature is immediately recognizable as one which is not available in release builds.

1 Like
10

This would also make it so that the table cell would be red with the version text being changed from “62” into “Beta 62”.

11

Assuming that the feature is specifically set to only work in beta builds. If it’s riding the train to release, the restriction would not be set at all.

1 Like
12

I encourage feedback on this idea (especially from @fscholz) , as I’d very much like to have a solution for this problem so I can finish updates to the Payment Request documentation without having to do it twice. :slight_smile:

13

I like this potential solution. I think this works fine — I don’t see any reason why something enabled in Beta would ever not be enabled in Nightly.

1 Like
14

I’ve summarized the next action items on the “nightly” matter in the relevant issue: https://github.com/mdn/browser-compat-data/issues/338#issuecomment-452275672

1 Like