Plugin Cards: Links with `.button-disabled` are still clickable

[costdev]

Props to @swissspidy for noticing this while testing Plugin Dependencies.

Currently, links with a href attribute and the .button-disabled class are still clickable.

We should prevent the default click handling for elements with the .button-disabled class.

While this appears to have been the case in earlier WordPress versions, it may be more apparent in the increased AJAX-ified experience added by the Plugin Dependencies feature.

Milestoning for 6.5 for awareness, though I welcome thoughts on whether this is something that needs to be handled in 6.5, or should wait until 6.6.

Testing Instructions

These steps define how to reproduce the issue, and indicate the expected behavior.

Steps to Reproduce

1. Navigate to Plugins > Add New Plugin.
2. Click "Install Now".
3. Once installed, click "Activate".
4. 🐞 Once activated, click on the disabled "Active" button.

Expected Results

When testing a patch to validate it works as expected:

• ✅ The link does not work.

When reproducing a bug:

• ❌ The link still works despite the .button-disabled class being present.

Previously, links with a href attribute and the .button-disabled class were still clickable.

This prevents the default handling for elements with the .button-disabled class.

I was thinking more of adding the disabled HTML attribute instead, because that's what we do on a fresh page load already:

​https://github.com/WordPress/wordpress-develop/blob/186eeafb6888431fdf445b2abf2036f0606edcd5/src/wp-admin/includes/plugin-install.php#L1007-L1011

But turns out there it is an actual <button> and here it's still a regular link.

So I suppose this makes sense 👍

Looks like the button-disabled class is also only used for shiny updates, so this shouldn't affect anything else either.

Requesting review from accessibility folks just in case.

[huzaifaalmesbah]

After applying ​PR 6207, I tried clicking the button, but it didn't work ✅

[audrasjb]

As the proposed PR is still being discussed, let's move this ticket to milestone 6.6.

On the "regression", I would agree that it's a regression from an accessibility perspective due to the markup of the link/button. Once that's improved, I think the removal of the automatic redirect is an enhancement that will benefit all users to be able to install and activate multiple plugins without leaving their current context.

Well, I'd argue the Activate link that stays clickable is a regression so it's not just accessibility, it's general usability.
I'm not opposed to 'AJAX-ifing' things. However, given this page is basically becoming sort of 'single page app', many other things should have been addressed. I do realize my consideration doesn't help solving the issue and I agree that right now we can only introduce a temporary fix. However, I'd still consider the changes to the install plugin page an incomplete development that will need to be addressed soon in the future.

The still clickable activate link is absolutely a bug. The accessibility regression I was referring to was the use of an a element rather than a button element, and the limited interaction options that provides (click/enter vs click/enter/space) while enabled. That, plus the incorrect semantics of using a here, and disabling it rather than use a button. While a temporary fix is in order for now, we should definitely make this correct and consistent for Plugin Dependencies, the Plugins/Themes screens (modals included), and Corewide as soon as possible.

plus the incorrect semantics of using a her

I'm not sure I clarified why many admin pages use an <a> element that behaves like a button.

Some new contributors may not know that, historically, WordPress supported the scenario where users may have JavaScript support disabled in their browsers. That's not a so rare scenario. Some companies or government bodies or other organizations may still disable JavaScript support as a security policy for their employees browseers. For yeaers, supporting 'JS off' has been a concern for any development in WordPress.

Many of these links in WordPress still work when JS is off. They just use a standard GET request e.g. update.php?action=upgrade-plugin&plugin={plugin filename here}&_wpnonce={nonce here}. Instead, when JS is on, they use an AJAX request counterpart e.g. update-plugin.

That's the way 'JS off' has been historically supported. I'm not saying that was a perfect approach as it creates a clear problem with links that behave like buttons but still semantically are links. This has been discussed many times bu tthere's no real way to fully addess this issue.

Personally I'm not opposed to stop supporting the 'JS off' scenario. That would allow to change these links and just use buttons. However, I think that is a decision that would need a broader discussion and can't be made in this PR.

[oglekler]

@joedolson can you, please, look at this? 🙏

Originally pasted this as a comment in the PR files thread, but it's more appropriate here.

I have a ​partially written ticket for raising the issue of changing link-buttons into real buttons. Just haven't had the time to finish it. I've just dropped it into a Google doc, if anybody wants to make comments. I wanted to make sure that the arguments were cogent and clear before actually opening the ticket.

Regarding next steps on this PR, I think we just need to choose one of the two temporary paths presented by @afercia and move forward with that for now.

[oglekler]

@joedolson what we are doing with this one? You have a comment that we have to make this patch in 6.6 and move some other work into 6.7. We have several hours before RC1, so, I wonder if we can make a decision now.

[joedolson]

This issue was resolved when the redirect behavior of the activation link was restored in [58254] against ticket #61319.

This issue could be reopened in the future if #61040 introduces a different solution for ajax plugin activation, but for now, this should be closed as invalid, since it does not apply to a behavior that's currently in core.