Data for legacy version of webextension.api.userScripts #25857
Conversation
rebloor
added
the
data:webext
|
On reflection, don't believe this is the right approach. |
There was a problem hiding this comment.
I assume you aligned on this approach with @Rob--W on Monday.
If the only overlap between the old and the new API is register(), then an alternative solution would be to mark all methods from the old API as deprecated, and only rename the legacy register BCD feature to register_legacy (with a good description).
Anyways, if we decide to introduce webextensions.api.userScripts_legacy, then shouldn't webextensions.api.userScripts reflect support for the new API, even if that's currently false for everything?
/cc @Elchi3 in case he has other ideas for this case.
@Rob--W |
Yes
I'm working on a PR to add the documentation for the new API now and will update the BCD shortly. |
| }, | ||
| "RegisteredUserScript": { | ||
| "__compat": { | ||
| "description": "RegisteredUserScript (Legacy)", |
There was a problem hiding this comment.
@rebloor, I'm curious about your motivations for including "(Legacy)" on each of the entries in this data. Is this an established practice? I assume this affects how entries appear in compatibility tables. Does it affect anything else on MDN? Other tooling?
There was a problem hiding this comment.
As far as I'm aware, we haven't had a similar situation in the past, so we're inventing "practice" here. In this situation, we have a userScript API implemented in Firefox only for Manifest V2 and an incompatible userScript API for Manifest V3 implemented in Firefox, Chrome, and Safari. In the MDN documentation readers will see the Firefox only version of the API marked up as "legacy" throughout. See mdn/content#37975 description is used as the title in the compatibility tables.
There was a problem hiding this comment.
I think I may have suggested this. If we render the BCD table for this feature, there would be no indication otherwise that this refers to the old API.
I notice that the features have no status set (like experimental, deprecated), which presumably is a special treatment. If it is forbidden to mark a webextensions.api feature as deprecated, then we should probably change that.
There was a problem hiding this comment.
Unless there's a change I'm unaware of, we have no plans to deprecate Manifest V2 ((https://blog.mozilla.org/addons/2024/03/13/manifest-v3-manifest-v2-march-2024-update/) so by extension we presumably have no plans to deprecate the Manifest V2 version of userScript. @Rob--W
In addition to including the word legacy in the descriptions, wouldn't the mdn_url indicate that it refers to the legacy API?
Summary
Initial PR for addressing the compatibility data needs of Bug 1943050 Enable userScripts API by default. This PR creates the compatibility data to complement the documentation changes in mdn/content#37975: