Fix context menu is obscured when edit message.

[NaccOll]

Related GitHub Issue

Closes: #7759

Roo Code Task Context (Optional)

Description

Adjust the position to avoid ContextMenu being blocked in edit mode, so as to achieve an effect similar to the ChatTextArea at the bottom

Test Procedure

In any conversation, select the user message, click Edit, and enter the @ symbol to test whether the context menu is working well.

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• Self-Review: I have performed a thorough self-review of my code.
• Testing: New and/or updated tests have been added to cover my changes (if applicable).
• Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
• Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Screenshots / Videos

Documentation Updates

Additional Notes

Get in Touch

NaccOll

---

Important

Adjusts context menu positioning in ChatTextArea.tsx to ensure visibility during message editing.

• Behavior:
  • Adjusts context menu position in ChatTextArea.tsx to ensure visibility during message editing.
  • In edit mode, sets left-6 and -mb-3 for context menu positioning.
• UI:
  • Removes relative class from the main container in edit mode to prevent layout issues.
  • Ensures consistent styling with flex and flex-col classes.

^{This description was created by for 578943c. 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 found some issues that need attention. While the approach to fix the context menu positioning is valid, there are concerns about potential layout regressions and the robustness of the solution across different viewport sizes.

[roomote]

Is this intentional? Removing relative from the main container and only applying it conditionally to non-edit mode could break the positioning context for child elements in normal mode. This might cause unexpected layout issues.

Could we keep relative on the main container and use a different approach for fixing the edit mode positioning?

[roomote]

The hardcoded positioning values (left-6 and -mb-3) might not work well across different screen sizes or container widths. Could we consider a more responsive approach?

Or perhaps calculate the position based on the container's dimensions?

[roomote]

I noticed that PR #7760 attempted to fix this issue using z-index adjustments. Have you tested if combining both approaches (z-index + positioning) would provide a more robust solution? This might handle edge cases better.

[daniel-lxs]

Thank you @NaccOll!