Media: bind the edit-image content handler once per frame

[jigneshbhavani]

MediaFrame.Select.bindHandlers() binds content:render:edit-image to editImageContent. MediaFrame.Post and MediaFrame.ImageDetails both extend MediaFrame.Select and call Select.prototype.bindHandlers(), then bind the same pair a second time: Post through the 'edit-image': 'editImageContent' entry in its handlers map, ImageDetails through a direct this.on() call.

Both subclasses define their own editImageContent, at post.js:407 and image-details.js:81. Since Select.prototype.bindHandlers() binds this.editImageContent, which resolves on the instance, both registrations on a given frame point at that subclass's own override rather than the one on Select. Checked on constructed frames: on Post and on ImageDetails the two registered callbacks are the same function reference, and each is identical to the subclass's own override and not to Select.prototype.editImageContent.

So the same method runs twice for one "Edit Image" click, building two wp.media.view.EditImage views and calling loadEditor() twice, which issues two image-editor Ajax requests. The second view replaces the first, so the visible result is correct and the first view and its request are simply discarded.

Removing the second registration leaves exactly one call to the subclass's own override, so behaviour is unchanged.

This PR removes the two redundant bindings and leaves the inherited one from MediaFrame.Select.

Listeners on content:render:edit-image, counted on freshly constructed frames:

frame	before	after
MediaFrame.Select	1	1
MediaFrame.Post	2	1
MediaFrame.ImageDetails	2	1

Introduced in [46461] (5.3), which added editImageContent and its listener to the select frame for #48028. post.js already carried the entry in its handlers map at that point, and image-details.js already had its own this.on() call, so both have been duplicated since.

Testing

1. Add a Classic block to a post, click inside it, then activate "Add Media".
2. Select an image so the Attachment Details panel appears.
3. Click "Edit Image".
4. In the network panel, filter on admin-ajax.php.

Before: two POST requests with action=image-editor and do=open for the same postid.
After: one.

In both cases the image editor renders with Crop, Scale and Image Rotation, and a single imgedit-panel-* element is present in the DOM.

The Classic block path is used above because it goes through wp.media.editor and involves no block editor media frame.

Results on this branch:

• grunt jshint:media: 98 files lint free
• grunt qunit:compiled: 566/566 passed, 0 failed, on both compiled.html and index.html

Trac ticket: https://core.trac.wordpress.org/ticket/65825

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: Driving the browser to count event listeners and Ajax requests before and after the change, tracing the duplicate binding back to [46461], and drafting this description. The change itself is two line removals. I reviewed the reasoning, ran the lint and QUnit suites, and confirmed the before and after request counts myself.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props bejignesh.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.