checkbox not working as expected in the admin panel

[acmoifr]

After upgrading to 6.9, even with 0 plugin, the checkbox(es) don't accept clicking and cannot be selected when using Firefox on the admin panel. It works well with Chrome.

Wordpress v 6.9
php 8.3
mysql 8.0

[threadi]

hi @acmoifr, welcome to Trac and thank you for your concern. Unfortunately, it is not possible for me to reproduce the problem described, e.g. via the Playground.

I would recommend clearing your Firefox browser cache to rule that out as the cause. Also check whether there are any updates available for the browser.

If you need general support, please contact the support forum: ​​​https://wordpress.org/support/forums/

[swissspidy]

#64353 was marked as a duplicate.

[siliconforks]

[60806] added alternative text for the CSS generated content of the checkbox, but support for this was added to Firefox in version 128, and older versions of Firefox (e.g., Firefox 115 ESR) get confused by this (and they no longer display the CSS generated content).

​https://caniuse.com/wf-alt-text-generated-content
​https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/content#browser_compatibility

[acmoifr]

Yes, you are true. It doesn't work only with the Firefox version for Windows 7.

But there are hundreds of thousands old Windows 7 Firefox versions users on the internet and they are not about to migrate to a new Windows version or to Chrome only to visit WordPress sites.

I hope that you will consider this as a bug. TY !

[jorbin]

I am not able to replicate this issue with Firefox 144 on a base install of WordPress 6.9.

The ​WordPress browser support policy is:

Last 1 Android versions.
Last 1 ChromeAndroid versions.
Last 2 Chrome versions.
Last 2 Firefox versions.
Last 2 Safari versions.
Last 2 iOS versions.
Last 2 Edge versions.
Last 2 Opera versions.
Browsers with > 1% usage based on can I use browser usage table

None of the versions of Firefox below the last two have > 1% usage which means that if this only affects old versions, I think it should be closed as wontfix.

It doesn't work only with the Firefox version for Windows 7.

@acmoifr Windows 7 hasn't been in extended support by Microsoft in over 5 years or mainstream support in over 10 years.

[Ov3rfly]

This should be fixed asap.

Remember core values: Democratize publishing, freedom to build, WordPress is designed for everyone, welcoming and inclusive.

WordPress should use ​plain and simple HTML code for a checkbox in admin area and let the browser draw it.

Weird CSS with negative margins and svg-images hardcoded inline in CSS content values is not designed for everyone.

[wildworks]

Related to #64266, [60885]

It is true that the latest WordPress does not support older browsers, but the inability to visually determine the state of form elements is a major issue that cannot be ignored.

For now, I suggest removing the alt syntax from ​here.

cc @joedolson

[joedolson]

The Firefox ESR 115 is hitting end of life in March 2026, and only exists to support Windows 7 through 8.1 and macOS 10.12 through 10.14. Windows 8.1 hit EOL on January 10th, 2023 - almost 3 years ago, and macOS 10.14 hit EOL on October 25th 2021, over 4 years ago. In principle, these systems are unsafe to use.

While it's easy to add that support back in, these are all systems that are *well* out of our official browser support.

I would ask where we'll draw the line at what we choose to support within the unsupported class of browsers. There are probably many other instances of CSS throughout core that are not supported by Firefox 115 - are we going to revert all of those? This may merit adjustments to our official browser support policy, but if so, we need to make it a policy change, not a one-off.

Windows 7 usage is still at 2.9% of Windows usage, so it's worth considering.

[siliconforks]

Replying to joedolson:

I would ask where we'll draw the line at what we choose to support within the unsupported class of browsers. There are probably many other instances of CSS throughout core that are not supported by Firefox 115 - are we going to revert all of those? This may merit adjustments to our official browser support policy, but if so, we need to make it a policy change, not a one-off.

It is perhaps worth noting that some other projects have a policy of supporting Firefox ESR versions - for example, jQuery:

​https://jquery.com/browser-support/

[acmoifr]

When I compare the panel versions of 6.8 and 6.9, I don't notice a special benefit with the new CSS on checkboxes. Perhaps I miss something...

In many countries, most of the private pc are running windows 7 and most of them are not able to use modern Windows versions. But the hardwares are clean and major tools work well.

[siliconforks]

Replying to acmoifr:

When I compare the panel versions of 6.8 and 6.9, I don't notice a special benefit with the new CSS on checkboxes. Perhaps I miss something...

The new CSS is intended to improve accessibility for people using screen readers. If you're not using a screen reader, there is not supposed to be any difference.

[jorbin]

There is a clear workaround to this issue: Use a browser that WordPress supports.

Based on this clearly falling outside of the current browser support policy and this ticket not being the best place to decide a change to that policy, I think this should be closed as maybelater with the maybe being based on the browser support policy changing at some point in the future.

[Ov3rfly]

There is a quick workaround to this issue for everyone with e.g. Firefox ESR 115 or probably also older Safari which are latest available versions for some users on their platforms.

<?php
/*
Plugin Name: Make checkbox usable again
Description: Make checkbox usable again in WordPress 6.9.x admin area, for everyone, see also core trac #64350
Version: 1.1
Update URI: false
Author: Ov3rfly 
Author URI: https://profiles.wordpress.org/ov3rfly/
*/
function mcua_func() {
        echo '<style type="text/css">.wp-admin input[type="checkbox"], .login input[type="checkbox"] { -webkit-appearance: checkbox; }</style>';
}
add_action( 'admin_head', 'mcua_func', PHP_INT_MAX );
add_action( 'login_head', 'mcua_func', PHP_INT_MAX );

[Ov3rfly]

Workaround for everyone with e.g. Firefox ESR 115 or probably also older Safari

[Ov3rfly]

Workaround for everyone with e.g. Firefox ESR 115 or probably also older Safari, added support for login page

[acmoifr]

It works fine now.
Trouble for old browsers is fixed now.

Thank you very much Ov3rfly !

( ps: sorry, I didn't found the keyword to close the thread )

[Ov3rfly]

@acmoifr The issue still has to be fixed in WordPress core for everyone.

The supplied small plugin is only a quick workaround as temporary solution for Firefox ESR 115 and probably also older Safari browser users who currently can not use WordPress 6.9.x admin area any more and somehow find this thread.

A proper patch would be removing the alt syntax as suggested also above by @wildworks

[wildworks]

I would ask where we'll draw the line at what we choose to support within the unsupported class of browsers. There are probably many other instances of CSS throughout core that are not supported by Firefox 115 - are we going to revert all of those? This may merit adjustments to our official browser support policy, but if so, we need to make it a policy change, not a one-off.

Based on this clearly falling outside of the current browser support policy and this ticket not being the best place to decide a change to that policy, I think this should be closed as maybelater with the maybe being based on the browser support policy changing at some point in the future.

After hearing these two comments, I believe they are certainly correct. As such, I'm leaning towards closing this issue as a maybelater.

Users encountering the issue can restore the native checkboxes with the following CSS, if necessary.

input[type="checkbox"]:checked::before {
  content: none;
}
input[type="checkbox"] {
  -webkit-appearance: auto;
}

[mydesign78]

Replying to wildworks:

I would ask where we'll draw the line at what we choose to support within the unsupported class of browsers. There are probably many other instances of CSS throughout core that are not supported by Firefox 115 - are we going to revert all of those? This may merit adjustments to our official browser support policy, but if so, we need to make it a policy change, not a one-off.

Based on this clearly falling outside of the current browser support policy and this ticket not being the best place to decide a change to that policy, I think this should be closed as maybelater with the maybe being based on the browser support policy changing at some point in the future.

After hearing these two comments, I believe they are certainly correct. As such, I'm leaning towards closing this issue as a maybelater.

Users encountering the issue can restore the native checkboxes with the following CSS, if necessary.

input[type="checkbox"]:checked::before {
  content: none;
}
input[type="checkbox"] {
  -webkit-appearance: auto;
}

Hi, I have Safari browser for IPhone X and I have same problem.
Where do you insert your CSS to resolve problem?
Thanks.

[wildworks]

Replying to mydesign78:

Hi, I have Safari browser for IPhone X and I have same problem.
Where do you insert your CSS to resolve problem?
Thanks.

As an example, write the following code in the functions.php of your active theme:

function restore_checkbox_style() {
        ?>
        <style type="text/css">.hogehoge{}input[type="checkbox"]:checked::before {content: none;}input[type="checkbox"] {-webkit-appearance: auto;}
        </style>
        <?php
}
add_action( 'admin_head', 'restore_checkbox_style' );
add_action( 'login_head', 'restore_checkbox_style' );

[mydesign78]

Hi, thanks for your reply.
I insert this script in the header of all site page but not function:

<?php
function restore_checkbox_style() {

?>
<style type="text/css">.hogehoge{}input[type="checkbox"]:checked::before {content: none;}input[type="checkbox"] {-webkit-appearance: auto;}
</style>
<?php

}
add_action( 'admin_head', 'restore_checkbox_style' );
add_action( 'login_head', 'restore_checkbox_style' );
?>

[wildworks]

I insert this script in the header of all site page but not function:

This CSS needs to be enqueued in the dashboard. Putting this code in your site template file will not work. Put this code in functions.php.

[Presskopp]

#64399 was marked as a duplicate.

[mydesign78]

Replying to wildworks:

I insert this script in the header of all site page but not function:

This CSS needs to be enqueued in the dashboard. Putting this code in your site template file will not work. Put this code in functions.php.

Hi, I insert it in function.php and make plugin also but your code not function with Safari for Iphone X.
Excuse me but .hogehoge it's a valid class??

[swissspidy]

#64422 was marked as a duplicate.

[peterwilsoncc]

With three duplicate reports in the two weeks since 6.9 was released, I'm strongly inclined to fix the issue.

As CSS ignores properties it can't parse, it's possible to take advantage of the improved content property by including the following:

.thing:before {
  content: "\f157";
  content: "\f157" / '';
}

This would be subject to the build tools not removing the duplicate property so that would need to be tested.

Adds fallback content properties for browsers that do not support alt text.

In each case that the content property includes alt text, it is preceded by a version without alt text for browsers that do not support the feature. For example:

.thing:before {
  content: "\f157";
  content: "\f157" / '';
}

[peterwilsoncc]

I've created ​PR#10636 with the changes mentioned above.

Testing using Firefox 115 via BrowserStack is showing the checkbox as checked when I visit the login screen. When using the dev tools on a more recent versions, the style browser is showing that the correct version of the content tag is applied, ie the one with the alt text.

[mydesign78]

Replying to peterwilsoncc:

I've created ​PR#10636 with the changes mentioned above.

Testing using Firefox 115 via BrowserStack is showing the checkbox as checked when I visit the login screen. When using the dev tools on a more recent versions, the style browser is showing that the correct version of the content tag is applied, ie the one with the alt text.

Hi, thanks for your reply but your link (10636) not function.

[sabernhardt]

#64392 was marked as a duplicate.

Thanks @sabernhardt, I've fixed each of those issues. I did a search for content:['"] and unable to find any instances in other files that I've modified.

[mydesign78]

How apply these patch? What file?
Thanks.

[sabernhardt]

#64430 was marked as a duplicate.

[sabernhardt]

#64438 was marked as a duplicate.

[peterwilsoncc]

Replying to mydesign78:

How apply these patch? What file?
Thanks.

@mydesign78 The pull request is for applying to the WordPress Develop repository, it is not intended for the released version downloaded from WordPress.org.

[sabernhardt]

I worked on a ​temporary plugin to apply changes from PR 10636 as inline styles, though I am not convinced that it is ready for installing on production sites. You could still test the plugin version on a staging site (if you cannot test the PR itself in a trunk installation).

The styles are added inline instead of replacing the entire files because some of the stylesheets use relative URLs for background images.

[sabernhardt]

#64456 was marked as a duplicate.

[wolf45]

Replying to sabernhardt:

I worked on a ​temporary plugin to apply changes from PR 10636 as inline styles, though I am not convinced that it is ready for installing on production sites. You could still test the plugin version on a staging site (if you cannot test the PR itself in a trunk installation).

The styles are added inline instead of replacing the entire files because some of the stylesheets use relative URLs for background images.

I would be interested in such a temporary plugin.

[wolf45]

Is there a temp fix for this too?

[wildworks]

Replying to wolf45:

Is there a temp fix for this too?

I believe ​PR 10636 should also fix the issue. Check out the screenshot included in this comment: ​https://github.com/WordPress/wordpress-develop/pull/10636#pullrequestreview-3601220617

[wildworks]

I temporarily started Firefox 115 ESR using the following method to test it, but please note that this may not be an officially recommended method and is for Windows.

1. Visit the 115.9.1esr archive page: ​https://ftp.mozilla.org/pub/firefox/releases/115.9.1esr/-. Download the exe file appropriate for your platform
2. Unzip it using 7-zip or similar
3. Launch /core/firefox.exe
4. Stop updates from the settings menu

​PR 10636 works fine and seems like a reasonable fix to me at this point.

However, I'm curious as to what problem the approach of explicitly applying empty alt text solves in the first place: are there actually any screen readers that read decorative icons as pseudo-elements?

[joedolson]

@wildworks Custom font icons are assigned to private use areas in unicode, which can be inconsistently announced by different screen reader/AT combinations. They may be ignored, and most commonly are, but they may also be read as irrelevant characters. It is difficult to know for sure how any given character could be read.

Most screen readers will read decorative icons inserted as pseudo-elements if there is a known spoken replacement for that character; some will do it for unrecognized characters, as well.

It's difficult to test for, since it's so highly variable - unique both to the specific character location, to the AT, and to the browser.

[wildworks]

@joedolson Thanks for the information.

I think a decision needs to be made on this issue. Personally, I prefer to move forward with ​PR 10636. There are no drawbacks to it other than the code being a little more verbose.

[peterwilsoncc]

Replying to wildworks:

I think a decision needs to be made on this issue. Personally, I prefer to move forward with ​PR 10636. There are no drawbacks to it other than the code being a little more verbose.

@joedolson Are you able to give me your thoughts on the a11y implications? I think the PR is a good solution (I wrote it so of course I do :) but I don't want to commit without accessibility sign-off. If the PR is no good, what approach should I take?

[joedolson]

@peterwilsoncc Yes, as far as I'm concerned that's good to go. PR approved!

[peterwilsoncc]

In 61480:

General: Use legacy content properties for CSS icons.

In modern browsers the CSS content property provides alt text support for assistive technology in the form display / alt text. This introduces support for legacy browsers that do not support the new syntax.

CSS content properties take advantage of the CSS cascade and browsers ignoring values they don't understand by adding duplicate content properties in the form:

content: display;
content: display / alt text;

Modern browsers will use the second property, legacy browsers will use the first.

Follow-up to [60885] for #63603.

Props acmoifr, joedolson, jorbin, mydesign78, ov3rfly, peterwilsoncc, presskopp, sabernhardt, siliconforks, swissspidy, threadi, wildworks, wolf45.
Fixes #64350.

[peterwilsoncc]

Reopening for merging to the 6.9 branch pending another committers approval.

[wildworks]

Reopening for merging to the 6.9 branch pending another committers approval.

I'll approve it, although it hasn't been decided yet whether 6.9.1 will be released...

[peterwilsoncc]

Thanks @wildworks, I'll hold off merging until the release is confirmed.

[jorbin]

​6.9.1 is confirmed