Bug in new compat data?

MDN
1

Hey

My contribution to the compat data went into the npm module, but when I use the macro on the page there seems to be some bugs, I went back to the data to check thinking I had some kind of error, but it all looks good.

Adding {{Compat("api.MediaStream")}} to https://developer.mozilla.org/en-US/docs/Web/API/MediaStream

Shows ‘null’ instead of ‘?’ and ‘false’ instead of ‘No’ when the version_removed value is added.

Is this a known thing? How can I report it? Shall I just add the new compat data anyway as it’s beta?

Thanks!

2

The diff for that edit shows that the line added was:

{{Compat("api.<span class="pl-s">MediaStream.</span>json")}  }

The <span> was likely added from a copy and paste. I prefer to avoid the “WYSIWYG” mode of CKEditor and use the “Source” view when adding KumaScript.

Would you like to give it another try? The call should probably be:

{{Compat("api.MediaStream.json")}}
3

Hey @jwhitlock

I added the compat data in the source view as required:
{{Compat("api.MediaStream")}} adding .json casuses the macro to fail.

That edit you saw must’ve been a old one when I was trying to get my data before it was published to npm.

5

You’re right, the call is {{Compat("api.MediaStream")}} like you originally said. Sorry I misunderstood the issue.

I’ve updated the document, and left it displayed, so that it is easier to talk about: MediaStream - Web APIs | MDN

The null appears for Opera, for the id property. Maybe version_added should be true, not null, to match Chrome.

MediaStream-1
MediaStream-11500×576 45.8 KB

The false appears in the label property for Chrome. I think version_added should be true, not false.

MediaStream-2
MediaStream-21182×234 20 KB

Many of these issues are only apparent when you view the table. There are many follow-on PRs for converted tables. Do you think you could create the follow-on change?

6

For sure, being able to preview the compat table would be extremely helpful!

I’ve had a good think about it now and my understanding is:

if we know the version the feature was removed, the feature must have been added at some point so version_added has to be either true or a value, it cannot be false or null.

At first I was migrating the data, but as my understanding grows I can fix these as I go.

It would be amazing if this logic was in whatever macro produces the table though! :smiley:

7

I think that it is better to detect this problem with linting, so that it is flagged when a pull request is opened, rather than after a table is rendered. I’ve opened https://github.com/mdn/browser-compat-data/issues/1328.

8

Sounds good to me!

I’ve made the changes and will check the page once it goes into npm.