Contrib.social

[Proposal] A different approach to the iFrame preview interactions

Open on Drupal.org →
Created on 20 September 2024, 3 months ago

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.

🌱 Plan
Status

Active

Component

Page builder

Created by

🇬🇧United Kingdom jessebaker

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024