fix: resolve context menu z-index issue by keeping text area in fixed position

[daniel-lxs]

Summary

Fixes the context mentions menu appearing behind other elements when editing messages by keeping the text area in its fixed position at the bottom instead of creating inline text areas.

Problem

Previously, when editing a message, a new text area would appear at the message's location in the chat. This caused the context mentions menu (triggered by typing @) to appear behind other chat elements due to stacking context issues.

Solution

Keep the text area always in its normal position at the bottom. When editing a message, show an "Editing message" indicator above the text area while the actual editing happens in the fixed text area. This ensures the context mentions menu stays in the proper stacking context.

Changes

• ✅ Text area now stays in fixed position when editing messages
• ✅ Added "Editing message" card above text area to show which message is being edited
• ✅ Added Escape key to exit edit mode
• ✅ Added click-outside functionality (click blurred background to exit)

Related Issues

• Fixes The editing information element is obscured (isEditMode = true) #7759 (context menu z-index issue)

Testing

1. Edit a message and type @ to trigger context mentions
2. Verify the context menu appears above all other elements
3. Press Escape or click the blurred area to exit edit mode

---

Important

Fixes context menu z-index issue by keeping text area fixed and adds draft persistence for message editing.

• Behavior:
  • Keeps text area fixed at the bottom in ChatView.tsx to resolve context menu z-index issue.
  • Adds "Editing message" indicator above text area during message editing.
  • Allows exiting edit mode with Escape key or clicking outside.
• Draft Persistence:
  • Introduces useDraftPersistence in useDraftPersistence.tsx to save, restore, and clear drafts.
  • Wraps ChatView with DraftPersistenceProvider.
• Testing:
  • Adds DraftPersistence.spec.tsx to test draft save, restore, and clear functionalities.
• Misc:
  • Updates ChatRow.tsx to handle edit mode using the fixed text area.
  • Fixes The editing information element is obscured (isEditMode = true) #7759 (context menu z-index issue).

^{This description was created by for c1332c5. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

Thank you for your contribution! I've reviewed the changes and the solution to keep the text area in a fixed position is creative and effectively solves the z-index issue.

Suggestions for Improvement

Accessibility Concerns

• The blur effect (blur-[1px] opacity-70) on line 1923 of ChatView.tsx might make it difficult for users with visual impairments to see the context. Consider using a more subtle visual indicator or making this configurable.
• The editing overlay (line 1947) should have proper ARIA attributes for screen readers (e.g., role="status" and aria-live="polite").

Code Quality

• Potential memory leak: In ChatRow.tsx (line 132), the message event listener for image selection during edit mode should be cleaned up when isEditing changes to false, not just on component unmount.
• UX improvement: When clicking outside to cancel edit mode, users might accidentally click on interactive elements. Consider adding a semi-transparent overlay behind the editing indicator.
• Code consistency: The blur value blur-[1px] appears in multiple places. Consider extracting it to a constant for maintainability.

Testing

The new editing overlay functionality would benefit from unit tests to ensure the escape key handling and click-outside behavior work correctly.

Overall, this is a good solution to the z-index problem. The above suggestions would help improve accessibility, prevent potential issues, and make the code more maintainable.

[mrubens]

Hmm, did you look at all into what it would take to get the right z-index for the context menu with the inline editing? Aside from the bug I think the inline editing is more expected behavior.

[daniel-lxs]

@mrubens Yeah, I did set the z-index all the way up but that didn't seem to do the trick, however I can try again since that's a simple change.

I will report back.

[daniel-lxs]

I dug into the z-index problem and it turns out it’s not really a z-index bug. Each ChatRow creates its own stacking context, so the context menu gets trapped inside and ends up behind later rows. That’s why just bumping z-index didn’t help, and why portals or dynamic z-indexes run into issues with Virtuoso.

The approach in this PR makes sense: instead of fighting stacking contexts, we move editing to the main input at the bottom, like WhatsApp and similar apps do. That avoids the whole z-index mess, keeps the UX consistent, and lets us reuse all the features of the main textarea. It’s also a lot simpler to maintain.

Much cleaner than trying to get inline editing to play nicely with CSS.

[NaccOll]

I'm sorry I only saw this question now. I usually use drag and drop to add files to the context, but I didn't test it thoroughly enough.

If the team still wants to inline edit, you can try the following changes:

webview-ui\src\components\chat\ChatTextArea.tsx:906-912

					"flex flex-col gap-1 bg-editor-background outline-none border border-none box-border",
					isEditMode ? "p-2 w-full" : "relative px-1.5 pb-1 w-[calc(100%-16px)] ml-auto mr-auto",
				)}>
				<div className={cn(!isEditMode && "relative")}>
					<div
						className={cn("chat-text-area", "flex", "flex-col", "outline-none", !isEditMode && "relative")}

By adjusting the position, the ContextMenu can be displayed in the outer container. Of course, the bottom left spacing of the ContextMenu needs to be optimized.

[daniel-lxs]

Thanks @NaccOll I tried to come up with something like this but couldn't, I told the rest of the team to evaluate this option as well, I'll let you know what we decide.

[NaccOll]

@daniel-lxs Okay. Actually, for bugs like this that are related to me, you can just assign the issue directly to me. I'll fix them. That's my fault.

[daniel-lxs]

@NaccOll I think you can create a PR with your fix, it's probably the solution that the team prefers

[NaccOll]

@NaccOll I think you can create a PR with your fix, it's probably the solution that the team prefers

Okay, right away

#7951