Overview
We now have a contextual menu for components thanks to #3458723: Implement context menu for hovered component. However, this is currently exposed via an icon that is displayed on the top left corner of the component. Let's experiment if we could expose this by right clicking the component both either within the preview or the component hierarchy list.
User interface changes

| Comment | File | Size | Author |
|---|---|---|---|
| #30 | Untitled.gif | 154.74 KB | gauravvvv |
| #23 | hover broken.gif | 149.65 KB | wim leers |
Issue fork experience_builder-3459249
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
fazilitehreem commentedComment #4
fazilitehreem commentedComment #5
lauriiiBased on the recording looks great! 👏 @fazilitehreem if you have a moment, it would be helpful if you could rebase this. 😊
Assigning for @jessebaker to review!
Comment #6
jessebaker commentedThanks @fazilitehreem I've left a comment on the MR.
Comment #7
jessebaker commented@fazilitehreem keep an eye on MR !93 - hopefully we will merge it soon.
Comment #8
fazilitehreem commentedI'll continue to work on this issue
Comment #9
wim leersSo is this issue's MR dependent on MR 93?
Comment #10
fazilitehreem commented@Wim This ticket is dependent on MR !93 as it uses the ContextMenu, which handles right-click functionality. Therefore, this requires the changes introduced in MR !93. This also needs some work around with ContextMenu implemented.
Comment #11
jessebaker commentedComment #12
fazilitehreem commentedComment #13
wim leers#10: thanks! Updated issue state to reflect that, and made MR 96 depend on MR 93 👍
Comment #14
fazilitehreem commented@jessebaker I did some work around with to check how it works with the current requirements. But with the limitation of , it requires an area to trigger the context menu. On adding the area, it blocks the other MouseEvents ( grab and click ) functionality of the component.
I tried with other ways like onOpenChange or to pass the reference of the actual component but still the blocker persists. To keep the all the MouseEvents on a single components this can be handle with custom code as done earlier in !MR 36 .
Was the added on purpose to add some required feature. Can we handle it with the menu?. Need your thoughts here. thanks
https://www.loom.com/share/f5c38bbadde245f1ba22593a6070547d?sid=5274b17c...
Comment #15
fazilitehreem commentedComment #16
wim leers#3460783: Implement component states landed yesterday, so this is now unblocked 😊
Comment #17
fazilitehreem commentedComment #18
wim leersThere are unaddressed reviews on the MR from 2 weeks ago, and it's not passing tests. There's many upstream changes that need to be merged in from the past 2 weeks.
Comment #19
fazilitehreem commentedComment #20
wim leersFailing the
UI eslintCI job and tests. 😅Comment #22
omkar-pd commentedSolved Merge conflicts, Fixed
UI Eslintand other tests, butCan access XB UI and do basic interactionskeeps failing. :(Comment #23
wim leersRan it locally, can confirm the hard failure on:
… but that looks like a legitimate test failure: the expectations of the test need to be updated.
Notice the
a few lines higher.
And so I tried this branch locally and … sure enough: it is broken. The appropriate outline only appears on click anymore, not on hover:
Comment #24
gauravvvv commentedComment #25
gauravvvv commentedComment #26
fazilitehreem commentedComment #27
fazilitehreem commentedComment #28
wim leersI bet merging in #3467859: Account for GitlabCI intermittent path differences in SDC CSS test will fix this 🤞
P.S.: you can record the screenshot/GIF I requested using https://www.cockos.com/licecap/ :)
Comment #29
gauravvvv commentedComment #30
gauravvvv commentedHere is the MR screen-recording, All tests are passing now. MR is ready for review

Comment #31
wim leers👏
Comment #32
jessebaker commentedI've reviewed - I found one small bug described on the MR and it needs some tests.
Comment #33
wim leersComment #34
fazilitehreem commentedComment #35
fazilitehreem commentedComment #36
jessebaker commentedComment #38
utkarsh_33 commentedThe problem was related to how the position is being calculated.
By introducing isPositionUpdated and using it to control when the context menu is rendered, the new code ensures that the menu only appears after its position has been recalculated for the new location.
I'll now add some tests for this.
Comment #39
utkarsh_33 commentedI think a bad merging has led to the failures of CI as it was passing here.I am assigning it to Jesse to review the changes that i have pushed along with the tests.
Comment #41
jessebaker commentedMerged! Great work everyone, thank you!
Comment #42
jessebaker commentedComment #43
kristen polYay! Duplicate and move up/down and delete! 😍
When trying to edit, the props form is hanging but I assume that's a different problem. I know there is a performance issue that's being worked on.
Comment #44
kristen polI have a video that shows the behavior I'm seeing on the right sidebar props form hanging (from when I was testing the dragging behavior):
https://youtu.be/j46NzjwEfp8
Comment #45
kristen polClearing the cache seems to have "fixed" the hanging props form issue (even though this was a fresh install).