Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid iframe page reload when grabbing iframe morph #1680

Open
neolay opened this issue Oct 15, 2024 · 2 comments
Open

Avoid iframe page reload when grabbing iframe morph #1680

neolay opened this issue Oct 15, 2024 · 2 comments
Assignees
Labels
📟 support inquiry Questions that can be answered without changing code

Comments

@neolay
Copy link

neolay commented Oct 15, 2024

What would you like to achieve?

I want to avoid reloading the iframe page when grabbing the iframe morph.

How are you trying to achieve that

I’m using only HTML morph to embed the iframe, but grabbing the HTML morph still causes the page to reload.

Additional Resources
It may be related to the morphic rendering process, but how can we avoid reloading the page during this process for the iframe morph?

Version
9c51c58

@neolay neolay added the 📟 support inquiry Questions that can be answered without changing code label Oct 15, 2024
@linusha
Copy link
Contributor

linusha commented Oct 15, 2024

I think this is related to how the morph model works internally - when you grab a morph, you are essentially removing the node from the DOM and insert it again when the morph is finally dropped.
I'll look into this and hope to get a fix out next week!


Note to self: This looks like good inspiration: https://gist.github.com/Akryum/5ef3c30e0c43a57135ad1e18d54cc03a

@linusha linusha self-assigned this Oct 15, 2024
@linusha
Copy link
Contributor

linusha commented Oct 28, 2024

Hey @neolay! Sorry that it took me a while.

So, I investigated this and have some not-so-great news:

I do not think we can prevent this from happening per-se. The reason is, as I said above, that iframes will be reloaded every time they are mounted inside of the DOM. There is no way of preventing that, this is the browser territory.

What is happening inside of lively when you grab a morph is that we basically dismount the node and remount it at a different place inside of the DOM. This we control, but to my knowledge there is no way around any remount triggering the reload.
So, concerning the general case - once we want to move an Iframe from an arbitrary position in the morph hierarchy to some other arbitrary place in the hierarchy, we do not get around remounting the node, and thus will always have a reload.

Some people reported luck with reordering inside of the same parent node, see the comments in this thread: https://stackoverflow.com/a/7434328. But that was more than 10 years ago and when I tested it in a more-or-less current version of Chrome, I had no success doing so.

What the Vue.JS implementation I posted above does is not dismounting the iframe, but setting its display to none, which will not trigger a reload and is a nice workaround for the way these SPA renderers work, where you will basically have a lot of remounting for "no reason". We had a similar solution in the past but spent a great amount of resources to move away from that and now only perform the minimal set of dom operations, so this won't save us.

We could figure out some workarounds, depending on what exactly you are trying to do. Is this just a pain-point during development when reordering morphs? Or do you have a specific application where you need to somehow rearrange iframes without them being reloaded? In that case, might it be an option to not use grab but only the move halo? Just changing the position of the iframe should not cause a reload.

Sorry to disappoint with a general solution. If you can provide more details on what specifically you are trying to achieve, we might be able to figure out a proper work-around.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
📟 support inquiry Questions that can be answered without changing code
Projects
None yet
Development

No branches or pull requests

2 participants