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)

  1. Events (keypresses, clicks, mouse movement) fired when the iframe has focus must be bubbled to the parent and handled there
  2. Panning when moving the mouse over the iFrame feels slightly laggy
  3. Zooming when the mouse moves over the boundary of the iFrame feels slightly off
  4. 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!)
  5. Positioning the right-click contextual menu

However there are actually far fewer interactions that we actually want to make inside the iframe

  1. Hovering over components (and slots)
  2. Clicking on components and slots.
  3. 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

  1. 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.
  2. Clicking/hovering on the invisible divs overlayed over the iFrame will display the borders meaning we don’t need any parent/iframe cross communication
  3. To allow drag and drop to work:
    1. Either we would need to hide this invisible overlay when dragging so items can be dropped into the preview.
    2. 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.

Command icon 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

jessebaker created an issue. See original summary.

lauriii’s picture

Version: » 0.x-dev
Assigned: Unassigned » jessebaker

bnjmnm’s picture

StatusFileSize
new49.8 KB

The 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

jessebaker’s picture

Title: [Proposal] A different approach to the iFrame preview interactions » Implement a different approach to the iFrame preview interactions
Assigned: jessebaker » Unassigned
Category: Plan » Feature request
Status: Active » Needs review
hooroomoo’s picture

Left some comments, awesome solution.

balintbrews made their first commit to this issue’s fork.

  • jessebaker committed 91e33ae7 on 0.x
    Issue #3475759 by jessebaker, balintbrews, hooroomoo: Implement a...
jessebaker’s picture

Status: Needs review » Fixed
wim leers’s picture

Lovely to see this landed! 🤩 Onwards and upwards! 🚀

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.