Editor: Show own presence in collaborative editing sessions

[dabowman]

What?

Adds self-presence visibility to the real-time collaboration (RTC) UI, letting users see their own avatar, cursor, and block highlight alongside other collaborators.

Closes #75838
Supersedes #76270

Why?

During collaborative editing, users had no visual indication of their own presence — they could see other collaborators but not themselves. This made it difficult to understand how others perceive them in the session. Showing your own presence provides spatial awareness and confirms that the collaboration connection is active.

How?

Self-presence in toolbar and popover

• The current user's avatar now always appears first in the CollaboratorsPresence toolbar button (using AvatarGroup).
• The collaborators list popover includes the current user at the top with a "You" label and a (you) badge.
• The current user's border color uses --wp-admin-theme-color (the admin accent color) instead of the collaborator color palette, visually distinguishing "self" from others.

Self cursor and block highlight (opt-in preference)

• A new "Show own collaboration cursor" toggle in Preferences → General controls whether the user's own cursor line and block highlight are rendered.
• When enabled and at least one other collaborator is present, the user's cursor badge and block highlight appear using the theme accent color.
• The cursor line (collaborators-overlay-user-cursor) is hidden for the current user to avoid overlap with the native caret — only the avatar badge label renders.

Avatar contrast ring fix

• The inner white contrast ring on avatars with a border color was invisible when a Gravatar image loaded, because CSS paint order renders inset box-shadow below content (the absolutely-positioned <img> covered it).
• Replaced with a ::after pseudo-element (z-index: 1) that always paints above the image. The initials fallback sets content: none since it doesn't need a contrast ring.

Block selection highlight alignment

• Added an inset box-shadow to the selected-block-outline mixin so the user's own block selection has the same white inner ring as collaborator highlights, creating visual consistency.

Files changed

• packages/editor/src/components/collaborators-presence/index.tsx — self-avatar in toolbar, sorted list with self first.
• packages/editor/src/components/collaborators-presence/list.tsx — "You" label and (you) badge for current user.
• packages/editor/src/components/collaborators-overlay/overlay.tsx — hide cursor line for own user.
• packages/editor/src/components/collaborators-overlay/use-render-cursors.ts — opt-in self cursor via showCollaborationCursor preference.
• packages/editor/src/components/collaborators-overlay/use-block-highlighting.ts — exclude own block highlight (existing behavior preserved).
• packages/editor/src/components/preferences-modal/index.js — new preference toggle.
• packages/edit-post/src/index.js, packages/edit-site/src/index.js — register preference default (false).
• packages/base-styles/_mixins.scss — white inset ring on selected-block-outline.
• packages/editor/src/components/collaborators-presence/avatar/styles.scss — ::after pseudo-element for contrast ring.
• packages/editor/src/components/collaborators-overlay/avatar-iframe-styles.ts — mirrored ::after fix for iframe.

Testing Instructions

1. Open a post in the editor with collaborative editing enabled (requires an RTC-capable environment).
2. Verify your own avatar appears first in the toolbar collaborators button.
3. Click the collaborators button to open the popover — confirm you appear at the top with "You" and a (you) badge.
4. Open Preferences → General and enable "Show own collaboration cursor".
5. With another collaborator in the session, verify your own cursor badge (avatar pill) appears in the canvas — the cursor line should not appear (only the badge).
6. With a Gravatar image loaded, verify the white contrast ring is visible between the colored border and the image on all avatars.

Testing Instructions for Keyboard

1. Press Ctrl+Shift+P (or Cmd+Shift+P on Mac) to open Preferences.
2. Tab to the General section.
3. Tab to the "Show own collaboration cursor" toggle and press Space to enable it.
4. Press Escape to close Preferences.
5. Shift+Tab to the collaborators button in the toolbar, press Enter to open the popover.
6. Verify the first item reads "You" with a (you) annotation.
7. Press Escape to close the popover.

🤖 Generated with Claude Code

[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.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: dabowman <davidabowman@git.wordpress.org>
Co-authored-by: chriszarate <czarate@git.wordpress.org>
Co-authored-by: maxschmeling <maxschmeling@git.wordpress.org>
Co-authored-by: pbearne <pbearne@git.wordpress.org>
Co-authored-by: smithjw1 <smithjw1@git.wordpress.org>

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

[github-actions]

There was a conflict while trying to cherry-pick the commit to the wp/7.0 branch. Please resolve the conflict manually and create a PR to the wp/7.0 branch.

PRs to wp/7.0 are similar to PRs to trunk, but you should base your PR on the wp/7.0 branch instead of trunk.

# Checkout the wp/7.0 branch instead of trunk.
git checkout wp/7.0

# Create a new branch for your PR.
git checkout -b my-branch

# Cherry-pick the commit.
git cherry-pick 903cef796600c0f745530e45123cac2178434c0b

# Check which files have conflicts.
git status

# Resolve the conflict...
# Add the resolved files to the staging area.
git status
git add .
git cherry-pick --continue

# Push the branch to the repository
git push origin my-branch

# Create a PR and set the base to the wp/7.0 branch.
# See https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request.

[t-hamano]

This PR has been manually backported in #76445.

[jasmussen]

@dabowman this change is quite aggressive for the default editing experience, especially in some darker contexts. Can you expand on the context for this change? I understand that it can be a constrast thing, but I would love for us to find something slightly more balanced/considered, as the hover-border is now about 3px around the whole block:

If we need a halo, can it be 1px at most, on the inside or outside but not both? And can it be semi opaque?

[dabowman]

Yeah, it's definitely bright on dark backgrounds.

We were getting feedback to make the users own presence clearer. The approach we decided on was to include the user in the list of collaborators and make their outline style match the collaborators' to reinforce the pattern and make presence indication consistent.

I think that's a good approach but ... contrast is an issue. I dug into this quite a bit earlier on and there are some potential solutions to make the style and other styles in the UI more responsive to their context so we're not using this belt and braces approach to contrast when we don't need to. But all of them were either super complex or kinda unreliable so I ended up going with the approach you see to make sure we covered our bases. But the contrast can be too much.

On collaborators, the contest is more needed for a11y. But I think that's less of a concern for the highlight style we're talking about here since the user has the block toolbar etc. to show their focus. The issue is just consistency and how we want to align it with the collaborators without introducing other issues.

I'm totally fine just rolling it back if you think that's the right call. I think we'll want to make it all consistent eventually but we might be able to cook up a more clever way of doing that across the UI.

I think we can make the case for doing it either way. Increasing the transparency on the outline might be the way to go. Or just ditching it. Whatever looks good to your eye. I was deep in the a11y requirements and the odd constraints of CSS and the editor canvas' odd way of applying styles when I made this.

[jasmussen]

I'm tempted to do without this as it is part of a piece of mixin code whose consequences are a bit hard to predict. But the motivation is nevertheless very good, so I took a stab at a refinement here: #76619

Let me know what you think!