-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Firefox 138 adds webextensions.api.webRequest.ResourceType.json
#26512
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
fixes mdn#26016 refs https://phabricator.services.mozilla.com/D230563 chore: mirror firefox_android from firefox
5c9a181 to
6437f31
Compare
Does this mean this feature is effectively not yet supported in Firefox? |
|
@caugner Yes, the feature is effectively not available. I don't know if there's another way around but I couldn't able to get resource type of |
Apologies for the confusion, if the feature is in fact not yet available, then it is too early to document in BCD. |
|
@caugner, where's the line for availability? Does it need to be available in a stable release of at least one browser? Can it be available behind a flag? Does Nightly/Canary/STP count? I haven't tested the feature yet, but it looks like the feature was implemented behind a flag in D230563 as part of bug 1858078. Per bug 1950836, the flag is being enabled by default in 138. |
|
Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs). |
json to webextensions.api.webRequest.ResourceTypewebextensions.api.webRequest.ResourceType.json
Co-authored-by: Simeon Vincent <[email protected]>
Generally, our data guidelines only require an "intent to implement" by at least one browser engine in order to record a feature in BCD, and this is enforced by requiring at least one If the feature is available behind a flag, then that can be documented in BCD, but we should only do this for features such as Temporal with significant interest by BCD consumers or users, because we cannot automatically test those flags, and the flag statements get removed once the feature becomes available without a flag in a non-preview release (see the flags lint). In this case, given that the feature appears to have been enabled in Firefox 138 beta, we can just set the version number accordingly. @rebloor Would you like to test that it actually works before merging this PR? |
|
@Rob--W I see that you were a reviewer on Bug 1858078 - Part 5: Add JSON tests for webRequest.ResourceType - could you take a look and tell us whether we're good to go with this one. |
Rob--W
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add the same change to declarativeNetRequest? It was supported with the same bug/patch stack: https://phabricator.services.mozilla.com/D229524#change-aViG2RKNWdeb
Co-authored-by: Rob Wu <[email protected]>
|
The commit is pushed and pinging as we can proceed. Also, thanks for all the efforts to the review and investigation. |
Rob--W
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically the value was accepted in the webRequest API since Firefox 135, but there was nothing that would trigger it until enabled in 138.
Being accepted in the webRequest API means that adding it as a value to the types filter in addListener was accepted instead of an error being thrown.
This is a subtle distinction that mainly matters for feature detection. In theory we could add this to "notes", e.g. "notes": "The "json" property is supported since Firefox 135, but requests of this type are only available since Firefox 138."
- https://bugzilla.mozilla.org/show_bug.cgi?id=1858078 (part 1 and part 5 of patch stack) - landed in Firefox 135
- https://bugzilla.mozilla.org/show_bug.cgi?id=1950836 (feature enables in Firefox 138)
|
@seia-soto if you want to make the change suggested by Rob, could you order it as follows |
Co-authored-by: Rob Wu <[email protected]> refs mdn#26512 (review)
|
Thanks @seia-soto |
Summary
This adds
jsontowebextensions.api.webRequest.ResourceType.Test results and supporting details
The test code is defined in Firefox source-code: https://phabricator.services.mozilla.com/D230563, but import attribution support on Firefox is blocking this.
Also,
declarativeNetRequest.ResourceTypeshould be confirmed in the future.Related issues
fixes #26016
refs mdn/content#38305