Problem/Motivation

The media module's settings forms have two links which use target="_blank" to force users to open the link in a new window/tab.

It's strongly preferable to let the user decide whether they want to open the link in a new window/tab, or the current window. Using target="_blank" effectively removes this choice from the user, and prevents the user from returning to the previous page by using the browser's "backwards" function. It isn't possible for users to override target="_blank" specified by a web page. The use of target="_blank" is very disruptive for several groups of users. The relevant part of WCAG is success criterion 3.2.5 Change On Request.

Neither of these links has a compelling reason to force a new window/tab to open.

The text of both links is a bit "click here", and would be improved by saying what they point to.

  1. The media settings form has a link to the oEmbed Security Considerations. It doesn't warn users that a new window will open. The link text would be better if it gave you a clue that it leads to the oEmbed spec.
  2. The oEmbed media source configuration (on the media type form) has a link to the Media settings form. This one actually warns the user that a new window will open, but it would be better if it didn't force this at all. The link text could be improved by saying it points to the media settings form.

Proposed resolution

  1. Remove target="_blank" from these links, and the "opens in new window" text.
  2. In MediaSettingsForm.php, change the sentence which links to the oEmbed spec. Suggested text: "Refer to oEmbed Security Considerations."
  3. In OEmbed.php, update the link text to say "You can specify a different domain for serving oEmbed content in the Media settings."

Remaining tasks

Patch.
Check the tests.

Comments

andrewmacpherson created an issue. See original summary.

pradeepjha’s picture

Assigned: Unassigned » pradeepjha
andrewmacpherson’s picture

There are other links in Drupal core which use target="_blank" without good reason, or don't warn users a new window will open. A policy issue is underway to address this.

pradeepjha’s picture

Assigned: pradeepjha » Unassigned
Status: Active » Needs review
StatusFileSize
new4.04 KB

From media module configuration:

  • Removed target="_blank" from these links, and the "opens in new window" text.
  • Also changed sentences on MediaSettingsForm.php and OEmbed.php file.

Status: Needs review » Needs work

The last submitted patch, 4: remove-target-blank-from-links-3142818-3.patch, failed testing. View results

pradeepjha’s picture

Assigned: Unassigned » pradeepjha

I'll be working on test case fail issue.

pradeepjha’s picture

Assigned: pradeepjha » Unassigned
Status: Needs work » Needs review
StatusFileSize
new5.01 KB
pradeepjha’s picture

The last submitted patch, 7: remove-target-blank-from-links-3142818-7.patch, failed testing. View results

Status: Needs review » Needs work

The last submitted patch, 8: remove-target-blank-from-links-3142818-8.patch, failed testing. View results

sivaji_ganesh_jojodae’s picture

Status: Needs work » Needs review
StatusFileSize
new5.53 KB
pradeepjha’s picture

Hey,
There is one minor change I forgot to update in my last patch #8. There was two `.` at last.

--- a/core/modules/media/src/Plugin/media/Source/OEmbed.php
+++ b/core/modules/media/src/Plugin/media/Source/OEmbed.php
@@ -301,7 +301,7 @@ public function buildConfigurationForm(array $form, FormStateInterface $form_sta
     $domain = $this->configFactory->get('media.settings')->get('iframe_domain');
     if (!$this->iFrameUrlHelper->isSecure($domain)) {
       array_unshift($form, [
-        '#markup' => '<p>' . $this->t('It is potentially insecure to display oEmbed content in a frame that is served from the same domain as your main Drupal site, as this may allow execution of third-party code. <a href=":url" target="_blank">You can specify a different domain for serving oEmbed content here</a> (opens in a new window).', [
+        '#markup' => '<p>' . $this->t('It is potentially insecure to display oEmbed content in a frame that is served from the same domain as your main Drupal site, as this may allow execution of third-party code. <a href=":url">You can specify a different domain for serving oEmbed content in the Media settings.</a>.', [
           ':url' => Url::fromRoute('media.settings')->setAbsolute()->toString(),
         ]) . '</p>',
       ]);

I'm updating it in this latest patch.

andrewmacpherson’s picture

Status: Needs review » Needs work

Thanks for working on this @pradeepjha and @Sivaji.

Review of patch #12:

  1. The change to the the message on the Media settings form - looks good.
  2. The change to the the help on the oEmbed media source settings form - looks good.
  3. The patch also changes the links on field widgets for media references. These aren't in the scope of the issue - it's just about the simple settings forms.

The links in the field widget are an acceptable use of target="_blank". Field widgets sometimes appears inside of complex forms where navigating away from the page could be disruptive. For example, when you have a media reference field inside a paragraph type. When editing a node with paragraphs content, a user might add a "media" paragraph. But if they follow the help link, then use the back button, the unsaved media paragraph will be gone.

Needs work:

Remove the changes to the field widgets.

pradeepjha’s picture

Assigned: Unassigned » pradeepjha
pradeepjha’s picture

Removed the changes from the field widgets.

pradeepjha’s picture

Assigned: pradeepjha » Unassigned
Status: Needs work » Needs review
andrewmacpherson’s picture

Status: Needs review » Reviewed & tested by the community

That's great.

  • xjm committed 735393d on 9.1.x
    Issue #3142818 by pradeepjha, Sivaji, andrewmacpherson: Remove target=...
xjm’s picture

Status: Reviewed & tested by the community » Fixed
Issue tags: +Needs followup

Huge +1 to this. I noticed this a couple weeks ago and had actually meant to file an issue. Glad someone else did.

These two remain:

media.module:    $elements['#media_help']['#media_add_help'] = t('Create your media on the <a href=":add_page" target="_blank">media add page</a> (opens a new window), then add it by name to the field below.', [':add_page' => $add_url]);
media.module:      $elements['#media_help']['#media_list_link'] = t('See the <a href=":list_url" target="_blank">media list</a> (opens a new window) to help locate media.', [':list_url' => $overview_url->toString()])

Both explicitly say that a new window will be opened, so I think that meets the a11y requirement.

One thing for @pradeepjha and @Sivaji: In the future, please provide interdiffs for your patches. That allows reviewers to evaluate your changes. Thanks!

Since this is a string change, it unfortunately just missed backport to 9.0 and 8.9. I considered backporting it anyway, but unfortunately the tradeoff of changed strings is that many users would not be able to read any of the message, which would be worse than this accessibility bug I think. But it is in 9.1.x.

I think there should be a sniff to warn devs about target="_blank", so tagging for a followup. Thanks!

andrewmacpherson’s picture

Thanks @xjm.

Since this is a string change, it unfortunately just missed backport to 9.0 and 8.9. I considered backporting it anyway, but unfortunately the tradeoff of changed strings is that many users would not be able to read any of the message, which would be worse than this accessibility bug I think. But it is in 9.1.x.

I agree with that. The relevant WCAG success criterion ("Change on Request") is at level-AAA. That's beyond our accessibility gate target, so we can say it's non-urgent on that basis.

I think there should be a sniff to warn devs about target="_blank", so tagging for a followup. Thanks!

I'll add that in the plan at #2702881: [policy, no patch] Formalize how external links are handled in core.

andrewmacpherson’s picture

Issue tags: -Needs followup

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.