Reactivation when scrolling

[fjenett]

Cells that are active are deactivated (and removed) when moving out of the window. This means they "restart" when coming back.

Related to #8 as there it is set wether the cell loads at all when becoming visible.

[fjenett]

Edited to be more precise.

[mlewisosu]

Florian, you asked: "Is the problem that they automatically reactivate (fixed by 1) or that they start over (from the beginning) when they become visible again?"

More the 2nd: but more specifically it's the load/startup time, more than that it's "from the beginning".

We've got some D3 in an iframe that takes some time to load and set up its interface the first time - so each time it scrolls off screen and comes back on, it redoes this initialization. Also we've got an iframe with a Unity plugin that gives a loading progress bar on first load that takes some time to wait for. If we scroll left then back, it goes through its loading/progress-bar ritual again.

We'd rather they not do this "reloading" if it can be avoided, and I was curious whether this re-initialization/reloading was being caused (and needed to be handled) by the content, the browser, or the set infrastructure.

[fjenett]

What is happening with the cells when they deactivate is that their content is actually being removed from the DOM (to speed things up that you are actually looking at). This means when they are being reactivated that is just like being loaded anew.

We are looking at several aspects here:

• Should they load once becoming visible (opening a set or scrolling into view)? This is being solved by the autoload setting now.
• Should they be allowed to unload when becoming invisible? I can add a setting to manage that.
• When should they unload if they don't do so automatically? For the Deborah Hay score we used the concept of only one active cell, so clicking another cell would deactivate the currently active one (unload it).

Generally this needs to be handled by the front end code. Although i could imagine sending a message into the iframes to let them know they should deactivate / reactivate.

[mlewisosu]

Yes - if we wanted to follow your Deb Hay model, our iframe would need to get the message telling it to return to poster/rollover just like your Vimeo cells.

[fjenett]

Messaging with the set ... this might be part of #13

[fjenett]

Matt, not sure how to read your answer. Are you in favour of the exact same behaviour as with Deborah's score? That means only one active cell and the set manages loading / unloading? Cell keeps running even if not visible?

The messaging system would be something else: the document inside the iframe (your code) would receive the message and would need to handle it. This also would mean not being able to go back to "poster state" (as that is outside the iframe, which can not be accessed from inside). In Deborah's case we just let the iframe content run until another cell is being clicked (which deactivates the active cell and removes it's content). Again that is handled by the set, not the cell.

[mlewisosu]

I've addressed the above question in #13
Regarding reactivation when scrolling... I guess it's sounding like if things could come back into view after scrolling having returned to their poster image and rollover behavior state, that would probably make the most sense.

This presumes you can give iframes poster-image-and-rollover behavior and return to it (or create a new cell that does this). We acknowledge that this means iframe content will reload when the poster image is again clicked.

[fjenett]

OK, that is doable. Thanks.

[martinleopold]

Will be implemented as part of #15