Fix requestFullscreen version info for Chromium.

[nh2]

See added link for backing reference.

Re-posting my notes while researching this (you don't need to read this, only this summary:

• MDN claims that Chrome 71 doesn't support the promise API.
• Comment on https://davidwalsh.name/fullscreen says

  I believe requestFullscreen() / exitFullscreen() return promises (at least seems to be the case in Chrome 73, Apr 2019)

• This guy claims it didn't work in Chrome in August 2018
• I found the Chromium change that introduced the Promise API:
  • diff
  • Gerrit
  • Comment setting Status: Fixed and Labels: M-71 suggests it was actually first available with Chromium 71 (this contradicts MDN).
    • Edit: It was the Unprefixed Fullscreen API that shipped with 71, but the Promise version of the vendor-prefixed API already shipped in 69 (see below).
  • Following https://www.chromium.org/blink/when-will-a-fix-ship-in-chrome-stable-or-canary to find out when it shipped. Gerrit shows Cr-Commit-Position: refs/heads/master@{#562946}.
    • https://storage.googleapis.com/chromium-find-releases-static/f24.html#f24f5da91960f0afa3b0e325ebab7c81ece796d4 says:

      • Commit f24f5da9... initially landed in 69.0.3446.0

• I updated the Chromium issue with my findings

---

A checklist to help your pull request get merged faster:

• Summarize your changes
• Data: link to resources that verify support information (such as browser's docs, changelogs, source control, bug trackers, and tests)
• Data: if you tested something, describe how you tested with details like browser and version
• Review the results of the linter and fix problems reported (If you need help, please ask in a comment!)
• Link to related issues or pull requests, if any

[queengooborg]

Thanks for the PR! Since we have the Promise-enabled syntax as a subfeature, let's use it to the fullest. Essentially, I would say that we can get rid of the note, and instead set "69" for the returns_a_promise version. WebView should also be set to "69" since it's based upon Chrome's releases starting with version 37, and since Opera is Chromium-based, it should be set to "51" and "48" for the desktop and Android versions respectively.

Overall, though, great work, and good find!

[nh2]

@vinyldarkscratch How can I render this table so that I can see whether the changes I make make sense? I coulnd't spot that in the README.

So far I'm editing it blindly, which is why I kept my change as small as possible.

[queengooborg]

You can run npm run render to render the compatibility table on demand. Doesn’t have the best styling just yet (a stand-alone style sheet is in the works), but it should give you something to work off of!

[ddbeck]

This doc also has some instructions for using the render script with an MDN preview (I haven't tried this recently though, so I'm not certain it renders exactly like the regular compat tables): https://github.com/mdn/browser-compat-data/blob/master/docs/testing.md#rendering

[jpmedley]

The webkit information should be done like this.

The information about the promise should probably be another item in the array. I've opened #4468, but will not hold up merging of this PR.

[jpmedley]

Chrome Android and WebView Android need to match whatever you do here.

Here's where you look up what is and is not in WebView.

[jpmedley]

This should say 69. https://storage.googleapis.com/chromium-find-releases-static/f24.html#f24f5da91960f0afa3b0e325ebab7c81ece796d4

[jpmedley]

As should Chrome Android and Android WebView.

[ddbeck]

Hi @nh2, do you plan to revisit this PR any time soon?

[ddbeck]

To keep this moving, I pushed a change responding to the review comments here. Thanks, everyone.

@jpmedley would you mind taking another look at this? Thank you!

[nh2]

Thanks for taking it up, I was on holiday and don't mind at all if you guys finish this.

Essentially, I would say that we can get rid of the note

Is it not useful to document on the page that the vendor-prefixed API and the non-vendor prefixed API are were released in 2 different versions (69 and 71 respectively)?

Otherwise people may be surprised that their unprefixed code doesn't work on 69 and 70.

[ddbeck]

Is it not useful to document on the page that the vendor-prefixed API and the non-vendor prefixed API are were released in 2 different versions (69 and 71 respectively)?

This is a good point and the data is useful, but it's captured in the schema a bit differently than a note (in this case, the data is already there; if you look beneath the changes in the diff, you'll see some "prefix" entries—these show that Chrome had the prefixed API from version 15, for example). In the MDN table, you can see this extended data by expanding the cells with the downward triangle.

[nh2]

@ddbeck That sounds good -- I don't mind at all which way it's shown, just wanted to point out that the PR currently doesn't show the info any longer.

[jpmedley]

The changes I requested still aren't in. Both the unprefixing and the support for promises need to be captured. As the PR stands, it only swaps one for the other.

[ddbeck]

@jpmedley I don't understand what you mean. Right now I'm reading the Chrome data in the file as:

• api.element.requestFullscreen
  • version_addded: 69
  • prefix: webkit; version_added: 15
• api.element.requestFullscreen.returns_a_promise
  • version_added: 71

What's missing?

[jpmedley]

I forgot that's how we decided to do promises. This PR looks right then.

[ddbeck]

Thanks! We'll sort out the promises structure in #4468 (it's still undecided and I didn't want to change anything in this file, absent a decision on the broader issue).

Going to merge this now. Thank you, @nh2!