Problem Summary
There are numerous tricky and fiddly technical challenges arising from our use of iFrames to display the page previews. These include (but are not limited to)
- Events (keypresses, clicks, mouse movement) fired when the iframe has focus must be bubbled to the parent and handled there
- Panning when moving the mouse over the iFrame feels slightly laggy
- Zooming when the mouse moves over the boundary of the iFrame feels slightly off
- You can click links/buttons inside the iFrame and it will navigate the user inside the iframe (this needs to be addressed in any case!)
- Positioning the right-click contextual menu
However there are actually far fewer interactions that we actually want to make inside the iframe
- Hovering over components (and slots)
- Clicking on components and slots.
- Crucially - dragging and dropping
At the moment, the UI to draw borders around components already exists in the parent and hovering a component simply sends the coordinates of the component to the parent and we display the border.
Proposal
- We build an invisible, overlaid, representation of the components present in the preview in the parent and overlay it over the iFrame preventing the user for interacting with the iframe directly at all.
- Clicking/hovering on the invisible divs overlayed over the iFrame will display the borders meaning we don’t need any parent/iframe cross communication
- To allow drag and drop to work:
- Either we would need to hide this invisible overlay when dragging so items can be dropped into the preview.
- Or we actually handle the drag and drop interactions on this fake overlaid layout.
Further thoughts
It would be important that when zooming the overlay would NOT scale but would still correctly draw over the components in the zoomed/scaled canvas.
Interaction with the content in the iFrame would no longer be possible - but this might be a good thing! Imagine now a component that renders a range slider - we have no way to differentiate between a user clicking and dragging the range input vs them clicking and dragging a component! A potential solution to this would be some kind of toggle between “interactive” and “editing” mode.
Related/impacted issues
I think this would, if not solve, certainly reduce complexity for a number of outstanding issues. This is not an exhaustive list.
- #3461035: [later phase] [needs design] Component drag handle
- #3473222: [test-only] Need to update the position of contextual edit component menu while zooming out/in in the canvas
- #3469672: The XB annotations and labels should not change size when zooming
- #3469673: Keyboard commands to zoom in and out should only impact the preview canvas
- #3475749: Pinch gesture zooming sometimes invokes OS zoom behavior
- #3469670: Allow zooming the canvas by pinching on a touchpad
- #3472650: Improve auto-scrolling when components are dragged
- #3466063: Middle click + drag and moving fast with the mouse miscalculates canvas scroll position
- #3458535: Middle click + drag doesn't work correctly if middle click is inside preview iframe
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | Screenshot 2024-10-16 at 1.48.16 PM.png | 49.8 KB | bnjmnm |
Issue fork experience_builder-3475759
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
lauriiiComment #4
bnjmnmThe A11y test is catching this contrast error where the bg/fg ratio is 3.26:1 when a smaller control like this needs to be at least 4.5:1
Comment #5
jessebaker commentedComment #6
hooroomooLeft some comments, awesome solution.
Comment #9
jessebaker commentedComment #10
wim leersLovely to see this landed! 🤩 Onwards and upwards! 🚀