Update WebDriver BiDi data #26203
Update WebDriver BiDi data #26203
Conversation
github-actions
bot
added
data:webdriver
| @@ -1958,11 +1958,11 @@ | |||
| "edge": "mirror", | |||
| "firefox": [ | |||
| { | |||
| "version_added": "114" | |||
| "version_added": "136" | |||
There was a problem hiding this comment.
@whimboo Can you confirm that addPreloadScript() is only fully supported from Firefox 136 (previously the sheet said 114)?
PS: Looks like the sync is doing it's job.
There was a problem hiding this comment.
We recently added support for the userContexts argument which was added to the BiDi spec after we marked it as done. You should see a similar change for browsingContext.setViewport as well.
Is it ok to reorder the version numbers for an API in the spreadsheet or should I avoid that? What should be in brackets and what not to make it helpful for you.
There was a problem hiding this comment.
So the reason browsingContext.setViewport doesn't show up here is that its status is set to "Partial", so we're just using the earliest version. If its status was "Complete", we would set a partial support entry for Firefox 117 and a full support entry for Firefox 138.
As for determining the versions, the script is currently ignoring the brackets, so in this example, it extracts [117, 127, 138], and uses the lowest version for partial support, and if status is "Complete", the highest version for full support.
There was a problem hiding this comment.
Good to know that it doesn't matter how the versions are listed. So I will re-org them most likely for our Firefox related status entries. Thanks!
I wonder how we should handle situations when an API gets a new parameter added at a later time while it is already marked as done. Would just adding a new version to the list be enough to get the version for a complete implementation updated?
mdn-bot
force-pushed
the
webdriver-bidi
branch
2 times, most recently
from
aeab047 to
8dbe383
Compare
(This PR was generated by the
update-webdriver-bidi-dataworkflow.)