Connection: Component updates - replace Modal with Dialog

[coder-karen]

Fixes CONNECT-390

Proposed changes

• This PR creates a new shared ConnectionDialog component, which makes of use of @wordpress/ui's Dialog component, replacing the Modal that was in place.
• This share component is now in use in disconnect-dialog/index.tsx , manage-connection-dialog/index.tsx, and owner-disconnect-dialog/index.tsx.
• Styling has been updated to match previous styling as best as possible.
• Additionally, the Owner Disconnect Dialog now makes use of a Text component from @wordpress/ui as well (for heading./ sub-heading), in line with it's sibling components.
• Step files have also been updated to make use of a shared ConnectionDialogTitle to help prevent an accessibility issue. The accessible name tracks the step — eg. success screen now announces "successfully disconnected", not the stale question.
• The Jetpack plugin Owner Disconnect Dialog relied on styles from the package despite being it's own component, so old styles are transferred across to the plugin for now to make sure that still looks as before (updating the Jetpack components will come in a later task).

Polyfill addition:

• New Dialog component (from @wordpress/ui) pulls in @wordpress/theme and @wordpress/private-apis under the hood. Older WP core (eg. 6.9) doesn't always ship those, so script fails to load. The fix here was to polyfill them via wp-build-polyfills, only registered when core's version is missing/incomplete — so most sites load nothing extra, and old sites get just the two small polyfills instead of Webpack bundling duplicate copies into every site's JS regardless of need.
• Additionally, the polyfill registrar dropped any handles/modules requested after the first consumer triggered registration. This PR's new connection consumer exposed that by registering before Social, causing Social's @wordpress/boot module to be dropped on WP < 7.0. Fix: register on every call, guarded only against duplicate hooks.
• Protect + Search e2e (package.json) — separate issue. These plugins' e2e builds have a hardcoded project list that was missing wp-build-polyfills, so the polyfill's JavaScript was never built into their test environments. The PHP asked to register the polyfill, but the files weren't there, so jetpack-connection.js got dropped again. Adding packages/wp-build-polyfills to their build scripts fixes it. (Jetpack/Boost/Social already had it).

Related product discussion/links

• See linked issue above.

Does this pull request change what data or activity we track or use?

No.

Testing instructions

On a Jetpack-connected site with this PR applied (locally or using the Jetpack Beta tester plugin):

• To test, click on the connection link on the My Jetpack page on the bottom right (eg 'Site and account connected'). This should look the same as before. .
• Click on Disconnect Jetpack and the disconnect dialog should look as it did before as well.
• If you click on 'Stay connected' you'll return to the main 'Manage Connection dialog', and can click on 'Disconnect my user account' to view the owner disconnect dialog, which should also look as before.
• Test on mobile screens, this should generally look similar to before, some slight differences.
• To test the disconnect survey, disconnect your user account via the My Jetpack page. Make sure it looks and behaves as before, including the 'Submit Feedback' button.
  • You may need to trigger the survey - I resorted to adding setIsProvidingFeedback( true ); within handleDisconnect in DisconnectDialog to get this to work, so testing locally and re-building for those changes (rebuild My Jetpack and dependencies) is what worked for me.

To test that the Jetpack plugin OwnerDisconnectDialog component styles still look as expected:

• Visit the Jetpack dashboard settings page at /wp-admin/admin.php?page=jetpack#/settings.
• You'll need siteConnectionMode to be returning true here:

  jetpack/projects/plugins/jetpack/_inc/client/searchable-modules/index.jsx

  Line 119 in a72efdf

  { siteConnectionMode && (

  (if testing locally, set this to true and rebuild Jetpack (plus dependencies)).
• In the search field, add a search for port.
• Scroll down, and see the Connect your WordPress.com account links in several cards (eg Forms). Click on this.
• The display and behavior should match what you see on trunk.

Additionally, to confirm the Polyfill changes have no impact, with WordPress 6.9 installed (can use a rollback plugin):

• On WP 6.9: load Social, Protect, Search, and Jetpack dashboards — each must render with no console errors, and the disconnect/manage/owner-disconnect dialogs must open and dismiss (Escape + backdrop). Repeat on WP latest to confirm no regression.

[github-actions]

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

• To test on WoA, go to the Plugins menu on a WoA dev site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin (Jetpack or WordPress.com Site Helper), and enable the update/connection-js-package-modal-to-dialog branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack update/connection-js-package-modal-to-dialog

bin/jetpack-downloader test jetpack-mu-wpcom-plugin update/connection-js-package-modal-to-dialog

Interested in more tips and information?

• In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
• Read more about our development workflow here: PCYsg-eg0-p2
• Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

---

Jetpack plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Backup plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Boost plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Search plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Social plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Starter Plugin plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Protect plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Videopress plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Mu Wpcom plugin:

• Next scheduled release: WordPress.com Simple releases happen semi-continuously (PCYsg-Jjm-p2)

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Inspect plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Wpcomsh plugin:

• Next scheduled release: Atomic deploys happen twice daily on weekdays (p9o2xV-2EN-p2)

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Automattic For agencies client plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Classic Theme helper plugin plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Paypal Payment buttons plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Wpcloud Sso plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Premium Analytics plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Agents Manager plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

[jp-launch-control]

Code Coverage Summary

Coverage changed in 3 files.

File	Coverage	Δ%	Δ Uncovered
projects/js-packages/connection/components/manage-connection-dialog/index.tsx	41/45 (91.11%)	-6.67%	3 ❤️‍🩹
projects/packages/connection/src/class-connection-assets.php	0/13 (0.00%)	0.00%	2 ❤️‍🩹
projects/packages/wp-build-polyfills/src/class-wp-build-polyfills.php	94/99 (94.95%)	4.04%	-4 💚

1 file is newly checked for coverage.

File	Coverage
projects/js-packages/connection/components/shared/connection-dialog/index.tsx	13/14 (92.86%) 💚

Full summary · PHP report · JS report

[Copilot]

Pull request overview

This PR migrates the Connection UI dialogs in the projects/js-packages/connection package from @wordpress/components Modal to @wordpress/ui Dialog by introducing shared dialog scaffolding and updating the existing disconnect/manage/owner-disconnect flows. It also prevents the Jetpack plugin’s Owner Disconnect Dialog from inheriting connection package dialog styles by namespacing its styles to the plugin.

Changes:

• Added a shared ConnectionDialog + ConnectionDialogTitle wrapper around @wordpress/ui Dialog to standardize dismissal and accessible naming.
• Updated Connection package dialogs, steps, styles, and tests to use the new shared dialog/title.
• Updated Jetpack plugin Owner Disconnect Dialog to use its own namespaced classes/styles and adjusted ARIA labelling.

Reviewed changes

Copilot reviewed 21 out of 21 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
projects/plugins/jetpack/changelog/update-connection-js-package-ui-pt5	Changelog entry for plugin-side style namespacing.
projects/plugins/jetpack/_inc/client/components/owner-disconnect-dialog/style.scss	Adds namespaced, self-contained styles for the plugin’s owner disconnect dialog.
projects/plugins/jetpack/_inc/client/components/owner-disconnect-dialog/index.jsx	Switches plugin dialog classnames/labelledby to the new namespaced selectors/IDs.
projects/js-packages/connection/components/shared/connection-dialog/index.tsx	Introduces shared ConnectionDialog wrapper and ConnectionDialogTitle for accessible naming.
projects/js-packages/connection/components/owner-disconnect-dialog/test/component.tsx	Updates tests to validate dialog accessible naming and heading semantics.
projects/js-packages/connection/components/owner-disconnect-dialog/style.scss	Removes styles that were specific to the old Modal/button styling and relies on shared disconnect styles.
projects/js-packages/connection/components/owner-disconnect-dialog/index.tsx	Migrates owner disconnect to ConnectionDialog and uses ConnectionDialogTitle + Text.
projects/js-packages/connection/components/manage-connection-dialog/test/component.tsx	Updates wording and continues asserting dialog accessibility behavior.
projects/js-packages/connection/components/manage-connection-dialog/style.scss	Adjusts layout/styling to work with the Dialog popup sizing/scrolling behavior.
projects/js-packages/connection/components/manage-connection-dialog/index.tsx	Migrates manage connection dialog to ConnectionDialog and ConnectionDialogTitle.
projects/js-packages/connection/components/disconnect-dialog/test/step-thank-you.tsx	Wraps isolated step test in a minimal Dialog context for Dialog.Title.
projects/js-packages/connection/components/disconnect-dialog/test/step-disconnect.tsx	Same as above for the disconnect step.
projects/js-packages/connection/components/disconnect-dialog/test/step-disconnect-confirm.tsx	Same as above for the confirm step.
projects/js-packages/connection/components/disconnect-dialog/test/component.tsx	Updates tests to assert dialog + heading semantics with step-driven accessible naming.
projects/js-packages/connection/components/disconnect-dialog/style.scss	Updates dialog layout/typography/styles for the new Dialog-based structure.
projects/js-packages/connection/components/disconnect-dialog/steps/step-thank-you.tsx	Switches the step heading to ConnectionDialogTitle for correct accessible naming.
projects/js-packages/connection/components/disconnect-dialog/steps/step-survey.tsx	Switches the step heading to ConnectionDialogTitle.
projects/js-packages/connection/components/disconnect-dialog/steps/step-disconnect.tsx	Switches the step heading to ConnectionDialogTitle.
projects/js-packages/connection/components/disconnect-dialog/steps/step-disconnect-confirm.tsx	Switches the step heading to ConnectionDialogTitle.
projects/js-packages/connection/components/disconnect-dialog/index.tsx	Migrates disconnect dialog to ConnectionDialog.
projects/js-packages/connection/changelog/update-connection-js-package-ui-pt5	Changelog entry for the Dialog migration in the Connection package.

[bindlegirl]

LGTM 👍 I tested on self-hosted and WoW.

While testing I did notice one thing that I'm not sure if it's deliberate or not. The Esc works on Disconnect account dialog but not the first one (Disconnect site). It's not a new behavior. I just noticed it now. I'll let you decide if it's worth aligning these two or not 🙂

[coder-karen]

Thanks for the review!

Are you referring to the Manage Connection Dialog (the first dialog that appears when clicking 'Site and account connected' from My Jetpack?). The dialogs that open from the two options within are both esc closable, so there is consistency based on the type of dialog as I saw it.

But I dug more based on your comment. There was a deliberate decision to only focus on those Disconnect modals here - #27643. But the reasoning for leaving the Manage Connection Dialog isn't clear. There was a risk with including it there - if there were an in-flight unlink request. But this can be covered by a ! isControlsDisabled gate.

So I opted to add this in. Tested a few flows, and everything looks ok to me.

[bindlegirl]

Thank you for adding that fix. Tested it again and it all looks good.

[coder-karen]

I've updated this PR with WP_Build_Polyfills related changes due to issues caught by failing tests.
Specifically, the polyfill registrar dropped any handles/modules requested after the first consumer triggered registration. This PR's new connection consumer exposed that by registering before Social, causing Social's @wordpress/boot module to be dropped on WP < 7.0. Current fix is to register on every call, guarded only against duplicate hooks.
I've explained more in the PR description, but adding a few additional reviewers based on #47367 specifically for those polyfill changes (if there is someone more appropriate feel free to add them) : @Automattic/triforce, @dhasilva

[simison]

These attributes were meant to protect any CSS reset or other h1 styles from leaking to the component; not as much as a way to customize the component.

Are the style overrieds (here and elsewhere in this file) to the core component really needed? Ideally we would just use the components as-is. Worth checking with Jetpack design team if that would work!

Long term these styles become pain to maintain since they're assuming the internal DOM structure doesn't change, and there aren't any other conflicting styles introduced in component later on.

[simison]

I'm looking into creating a lint rule to avoid using the internal gcd tokens: WordPress/gutenberg#80952

[simison]

Similar to above question, could we simply use the button component as-is without overriding its styles entirely? Otherwise, there's little point in using a shared component in the first place.

[simison]

This looks such a thin wrapper than perhaps we could just use Dialog.Title directly? Or what's the value it brings?

[simison]

Love seeing us adopt UI components, but I'd suggest try remove all CSS and add back only stuff that changes element positions/widths and cannot be done using Stack, i.e. structural CSS. All the visual styles should come from the design system; if not from components, then from --wpds-* tokens for things like colours, font size and border radius for more custom, Jetpack-specific elements. Otherwise we basically lose most of the value of using design system components in first place; you're only using the functionality (like dialog) but not the shared styles.

For cases where you do need the functionality but not the styles, there often is "unstyled" variant which can be used, but that should be more of an exception than rule.

Worth running this by Jetpack design team to see if more native look would work for them and what tweaks that might require!

[coder-karen]

Thanks for taking a look here @simison!

Worth running this by Jetpack design team to see if more native look would work for them and what tweaks that might require!

For the sake of just modernizing to use the Dialog component as in this case, it may not be worth it (especially with the polyfill additions here as well for now), as it would be more than just the modals being updated.

I'm leaning toward leaving the modals now - we're updating other components throughout which is also resulting in a net CSS reduction so for the sake of the complexity this specific PR would introduce it seems better to drop it.

I agree it would be good to have an overhaul of the design of components though. That's outside the scope of our current project (for which these updates are not the primary changes), but we'll have this as a follow-up. I'll mark this as draft for now and may then close it later... the polyfill changes might be useful later somewhere though.

[dhasilva]

Thanks for the ping — I looked at the wp-build-polyfills changes specifically.

The diagnosis is right, and the fix is the minimal one. The old $hooked flag was doing double duty: "have I added the hook?" and "have I done any work at all?". The deferred path was never actually broken (the closure reads self::$requested at fire time, so everyone who called before wp_default_scripts got picked up); the bug was specific to the synchronous branch, which registers from a snapshot of $requested taken at call time. So a late consumer ended up recorded in the map but never registered — get_consumers() would report @wordpress/boot as requested while wp_register_script_module() had never been called for it. Silent and invisible, exactly as you describe.

A few consequences worth weighing before this lands.

1. The polyfills must only be registered on our own dashboard pages

This is the one I'd really stress. Connection_Assets::configure() is hooked on plugins_loaded priority 1 and register_assets() on wp_loaded, so the new consumer fires on every request in every plugin that bundles connection — front end, block editor, REST, cron. wp-private-apis has a force_threshold of 7.1, and the Gutenberg escape hatch only applies from GB 23.5+, so on the current install base (WP 6.x) that means core's wp-private-apis is deregistered and replaced with our bundled copy site-wide.

That's a real problem for other plugins, not just for us: anything that depends on wp-private-apis — core's own editor packages, Gutenberg, and any third-party script registering against that handle — will now be running against our build rather than the one core shipped. Replacing a core handle outside the pages we control is the kind of change that surfaces as "the editor broke and nobody knows why".

Every other consumer in the monorepo is page-scoped for this reason (Social gates on should_enqueue_block_editor_scripts(), My Jetpack registers inside its own enqueue_scripts). The connection consumer needs the same treatment: register the polyfills only on the admin/dashboard screens that actually enqueue jetpack-connection, not globally on wp_loaded.

Worth noting the registrar change is what makes this bite. Before, a register() call arriving after the first one was inert, so an unscoped consumer was accidentally harmless. Now every call takes effect wherever it runs, so unscoped call sites are no longer forgiving.

2. Repeated force-replacement churn

register_scripts() skips already-registered handles unless $force is true, in which case it does remove() then add(). WP_Dependencies::remove() is unset( $this->registered[ $handle ] ) — it destroys the whole _WP_Dependency, including extra: inline scripts, wp_localize_script() data, wp_set_script_translations(), and wp_script_add_data() strategy/group flags.

Under the old code that demolition happened once, at a predictable point. Now it happens once per late consumer, at arbitrary points through the request, and anything attached to wp-notices / wp-private-apis between two register() calls is silently discarded. Core 6.9 doesn't attach inline scripts to those handles today, so this isn't an immediate breakage — but it's a new failure mode with no test covering it.

Related: each call now re-processes the whole accumulated set rather than the delta, so a consumer that only wants @wordpress/boot still triggers a full classic-script pass (with the remove/add churn) over every handle any earlier consumer requested. And this path is routine rather than theoretical — plugins commonly register scripts on init, which instantiates wp_scripts() before wp_loaded, so connection takes the synchronous branch and every later consumer takes it again.

Suggestion: track which handles have actually been registered (and at what threshold), and process only what's new on subsequent calls, re-processing an existing handle only when the threshold rose. Same fix, no churn, no lost extra data.

3. Side effect: the threshold contract changed

The docblock promises "highest threshold wins" when consumers disagree on $wp_version_threshold. On the synchronous path that was previously unreachable — registration had already happened with the first caller's threshold. It now genuinely re-forces. That matches the documented contract, so it's arguably a fix too, but it does mean a late consumer can force-replace handles that were left alone earlier in the request.

4. Test notes

• The new regression test writes into the package's real build/modules/boot/index.asset.php and mkdirs into build/, restoring only the file in finally — a crash or timeout leaves a fake version => 9.9.9 asset behind in the working tree. Every other test in the file injects a temp $build_dir through the private methods; this one can't because register() hardcodes dirname( __DIR__ ) . '/build'. Making the build dir injectable would be cleaner than mutating build output.
• set_up() now calls remove_all_actions( 'wp_default_scripts' ) and unsets $GLOBALS['wp_actions']['wp_default_scripts'] without restoring them. The statics are restored via reflection in tear_down(), these aren't — so core's default script registration stays stripped for anything else running in the same process.
• Would be good to add a test asserting that a second register() call doesn't clobber data attached to an already-registered polyfill handle. That's the behavior the new "run every time" model puts at risk.

5. Packaging

Connection now hard-requires automattic/jetpack-wp-build-polyfills, whose .gitattributes marks build/** as production-include (~430K production build). That ships into all 10 plugins bundling connection, on top of the lockfile fanout across the repo. Not a blocker, just worth being deliberate about — it's a fairly wide dependency to take on for two handles.

---

Summary: registering on every call is the right fix for the dropped-handles bug. The blocker for me is scoping — the polyfills should only be registered on our dashboard pages, since force-replacing wp-private-apis globally will affect other plugins. The delta-registration and test points are suggestions.

Generated by Claude.

[coder-karen]

Thanks @dhasilva , appreciate the info! This is incredibly helpful.
I'll close this issue out as the changes do not warrant the extra dependencies at this stage but if we return to this in some other form (or if another package finds itself in a similar situation), this info will be very helpful in that case.