Add RTCDataChannel-binaryType.html from PR13499

[youennf]

No description provided.

[youennf]

@lgrahl, made some changes to the original test. PTAL.

[lgrahl]

LGTM apart from a nit.

[youennf]

Sure, I can remove them, they kind of make sense to me though.
The test is about setting a value.

Before setting, check the value.
After setting, check the value.
After failing to set the value, check the value.

[lgrahl]

Works for me then.

[alvestrand]

@youennf if this is ready and still useful, can you hit merge?

[dontcallmedom]

@foolip can you help me understand what's making the CI stuck on this PR? (if not you, who should I ping?)

[stephenmcgruer]

@foolip can you help me understand what's making the CI stuck on this PR? (if not you, who should I ping?)

You can always ping @web-platform-tests/wpt-core-team for a more general set of people that can help :)

The problem here is that the PR is so old that there have been several infra shifts on the Taskcluster side that make old PRs incompatible. That said, if reviewers are happy with it and the test seems solid, I'm happy to override the CQ and admin-merge it - please let me know.

[dontcallmedom]

@stephenmcgruer then please go ahead and admin-merge - thanks!

[frivoal]

Force merging PRs with lint errors isn't nice, as it blocks every other PR. Now fixed by #25944

[sideshowbarker]

Now fixed by #25944

Thanks for catching that and fixing it

Force merging PRs with lint errors isn't nice, as it blocks every other PR.

Nobody realized it had lint errors. Those went unnoticed among the other CI errors it was triggering due its age (see previous comments here) and was force-merged because those CI errors were non-blockers for this case. Nobody would have intentionally merged it knowing it had lint errors as well.

[stephenmcgruer]

Force merging PRs with lint errors isn't nice, as it blocks every other PR. Now fixed by #25944

Echoing Mike; thanks for catching this and taking care of it! My apologies for not considering that as a possibility, we should considering taking a(n unofficial?) policy of cherry-picking changes like this one to new PRs rather than force-merging the original PR. (Or we could see if we can fix Taskcluster to not rely on the base commit for some of its mechanisms, cc @jgraham for that).

It's a pity that even when GitHub claim its the default, most PRs from forks that I come across I cannot modify in any way and instead have to rely on the original author for minor fixups or rebases.

[jgraham]

FWIW I think the best option here would have been to simply rebase the branch. If we didn't have access to the underlying branch it might have indeed been good to create a new PR.