Add rel="noopener" to target="_blank" links by default in image widget

[audrasjb]

Core previously introduced rel="noopener" attribute to target="_blank" links –which is fine– but I think image widget should also add this attribute to image link.
I know there is already a "Link rel" text input but I think we should add rel="noopener" attribute by default when "Open link in a new tab" option is checked and "Link rel" is empty.

[audrasjb]

Adds default rel noopener attribute when using target blank in media widget and Link rel field is empty

[SergeyBiryukov]

Related: #37941

[audrasjb]

Related: #43290 (menu walker)

[welcher]

As per my comment in #43290, I'm thinking we should also add the noreferrer here as well to be consistent

[audrasjb]

Adds both noopener and noreferrer values and refreshes the patch against trunk

[welcher]

Patch looks good to me - thanks for updating @audrasjb!

[pento]

Similar to #43290, this change is good to land in 5.2. It could do with some unit tests.

[desrosj]

@welcher @audrasjb are you able to add some unit tests for this before 5.2 beta 1 in a little under 2 days time?

[welcher]

Adds some unit tests

[audrasjb]

Thanks @welcher you rock!

[welcher]

Removes needless parameter from tests setup

[afercia]

As mentioned on #46421, I'd suggest to investigate on the actual usefulness of noreferrer:

• it was used to support old browsers that had no support for noopener, see ​https://mathiasbynens.github.io/rel-noopener/ under "Recommendations" for browsers details
• seems redundant after [41741] see #42036

[audrasjb]

@afercia I think both of the rel attributes should be added, in order to keep some consistency with ​https://developer.wordpress.org/reference/functions/wp_targeted_link_rel/
If we want to remove noreferrer, I believe we should remove it from that function :-)

[afercia]

@audrasjb right. Then, keeping the patch as is (same for the other related ones) seems to most appropriate thing to do. I'd suggest to open a separate ticket for discussion though.
(also, noting those functions lack a docblock @since tag)

[afercia]

For consistency with images added in the post content, I'd think the behavior should be different.

In the post content, images get noopener noreferrer even if users set their own value. Also, when reopening the details modal, the "rel" field is populated with noopener noreferrer plus any custom value previously added:

Instead, with this patch noopener noreferrer are added only if the field is empty. Also, when reopening the details modal the field is empty.

[audrasjb]

@afercia You're right. We should use the same behaviour as post_content. I'll try to have a patch ready in the next few hours. Otherwise, we should punt it to the next release.

[audrasjb]

Use wp_targeted_link_rel() to add rel attributes

[audrasjb]

Rel attributes are added with wp_targeted_link_rel() function so they are always here in front

[audrasjb]

@afercia with 4328.5.diff, the rel atributes are added with wp_targeted_link_rel() so they are always added in front-end.

[afercia]

@audrasjb personally I like this new approach. Not my area of expertise though. I think there are two options:

• change this ticket (and the other related ones) to type: bug, as this is about security hardening and it was missed in the original ticket #43187. Having a few more days may help asking a review from the ones involved in #43187 who have better knowledge on this issue
• punt to 5.3 :)

[audrasjb]

Ok, thanks for your feedback :)
I'm changing both #43290 and #43280 to type "bug" to see if we can have a review in the next few days or if we have to punt them to 5.3.
(I think #46421 if ready to ship by the way)

[pento]

In 45144:

Widgets: Add rel="noopener noreferrer" to links with target="_blank" in the Image widget.

Props audrasjb, welcher, afercia.
Fixes #43280.