This feature adds the "rel" attribute to form elements, which makes it possible to prevent window.opener from being present on websites navigated to by form elements which have rel=noopener and prevent the referer header from being sent with rel=noreferrer.
This has low interoperability risk because Safari has already shipped this feature. There are no negative signals from Firefox.
I don't think this feature will be used in tandem with other features.
I don't think it would be challenging for developers to start using this right away. I don't think it would be helpful to make a polyfill, build on top of this, or do significant outreach. This is already documented as supporting form elements on MDN: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel
There are no security considerations with this feature.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
This does not deprecate any APIs and does not have any particular risk for WebView.
No DevTools support will be needed.
103
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
No anticipated spec changes.LGTM1
The only tangible risk I can think of is that there are sites that depend on opener but has rel=noopener in their form element. It seems unlikely and considering it's already shipped in WebKit, I think this is fine.
/Daniel
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKLB_Uy%2BgoHtbkNdj-mqJu7Li0g6UXmMc-vRePJDYygUQ%40mail.gmail.com.
LGTM1
The only tangible risk I can think of is that there are sites that depend on opener but has rel=noopener in their form element. It seems unlikely and considering it's already shipped in WebKit, I think this is fine.
/Daniel
On 2022-05-03 19:17, Joey Arhar wrote:
Contact emails
jar...@chromium.org
Explainer
None
Specification
https://html.spec.whatwg.org/multipage/forms.html#attr-form-rel
Summary
This feature adds the "rel" attribute to form elements, which makes it possible to prevent window.opener from being present on websites navigated to by form elements which have rel=noopener and prevent the referer header from being sent with rel=noreferrer.
Blink component
Blink>Forms
TAG review
TAG review status
Not applicable
Risks
Interoperability and Compatibility
This has low interoperability risk because Safari has already shipped this feature. There are no negative signals from Firefox.
Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1509346)
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/538157ee-9133-1fc1-4b49-7761f97804bf%40gmail.com.
LGTM3.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/00000000000053ad5305de2f4534%40google.com.