Regression in 0.17.0: Jetpack SSO override CSS is now outweighed by Jetpack's own CSS due to load-order change (#807)

[motoki-taro]

Describe the bug

Description

Since 0.17.0, the login form controls (auth code input, backup methods, etc.) are hidden again when Jetpack SSO is active, even though the CSS override that fixes this (originally for Automattic/jetpack#3747) is still present in the codebase, in user-edit.css:

​css .jetpack-sso-form-display #loginform > p, .jetpack-sso-form-display #loginform > div { display: block; } ​

What I checked

Using browser devtools on the wp-login.php two-factor challenge screen:

• user-edit.css is enqueued and loaded (confirmed in the <head>).
• The .jetpack-sso-form-display #loginform > p / > div rule does match the hidden element and shows up in the matched rules panel.
• However, it is struck through / overridden — a competing rule from Jetpack (same specificity) wins the cascade.

Suspected cause

I believe this is a side effect of #807 ("Move class-two-factor-core.php login styles from inline to enqueued stylesheet"), merged between 0.16.0 and 0.17.0.

• Before Move class-two-factor-core.php login styles from inline to enqueued stylesheet #807, this override lived in an inline <style> block printed directly in the 2FA challenge page body, right before login_footer(). That placed it very late in the document source, so it won the cascade tie-break against Jetpack's own SSO CSS regardless of specificity.
• After Move class-two-factor-core.php login styles from inline to enqueued stylesheet #807, the same rule now ships in user-edit.css, enqueued via wp_enqueue_style() and printed in <head> (early in the source). If Jetpack prints its own conflicting rule later in the document (e.g. via a login_head/login_footer-hooked inline style), it now wins the tie, since both rules have equal specificity and CSS cascade order is decided by source order for ties.

So the rule itself was never deleted — the move to an enqueued stylesheet in #807 unintentionally changed its position in the cascade relative to Jetpack's own CSS.

Steps to Reproduce

Steps to reproduce

1. Activate Jetpack with SSO enabled.
2. Install Two Factor 0.17.0.
3. Trigger the two-factor challenge screen on wp-login.php for a user with 2FA enabled.
4. Inspect the hidden #loginform > p/> div element in devtools — the .jetpack-sso-form-display override rule matches but is crossed out / overridden.

Expected behavior

The two-factor prompt should remain visible, as it did in 0.16.0.

Suggested fix

Increase specificity (or add !important) on this specific override rule so it isn't sensitive to enqueue/source order, or confirm the enqueue priority so user-edit.css is guaranteed to print after any Jetpack-injected style on this page.

Environment

• Two Factor version: 0.17.0 (regression from 0.16.0)
• WordPress version: 7.1.2
• Jetpack version: 16.2
• Browser: Google Chrome

Screenshots, screen recording, code snippet

No response

Environment information

No response

Please confirm that you have searched existing issues in this repository.

Yes

Please confirm that you have tested with all plugins deactivated except Two-Factor.

Yes

[kasparsd]

Thanks for reporting the issue @motoki-taro! Would you be able to test the potential fix in #1009? Thanks!

[motoki-taro]

@kasparsd
Sorry for the delayed reply. Adding the body prefix made the controls appear! Thank you so much.