• Problem: my block animations were not working on Edge or mobile devices, but it was working on Google Chrome while logged in as an admin.

    Debugging: When debugging the animated elements, they did, in fact, animate onto the page, but they were not visible. It looks like the o-anim-ready class was not added to make them appear in the browsers/devices where they were broken. I looked at your plugin’s source code to see when/why that class would get added, and it’s in /wp-content/plugins/otter-blocks/build/animation/frontend.js where there is a listener on the window element listening for the load event that would wrap up and reveal the animated blocks.

    Hypothesis: For whatever reason, this event was not firing in Edge/mobile. My hypothesis is that the browser may have executed it after firing that event, so by the time the listener was added, it was listening to something that was already done. In my case, the script itself is being loaded in the footer with the defer strategy applied.

    Bandaid Solution / Workaround: I load another JS script that, when it’s run immediately, it checks the ready state before adding the listener so that it can run right away if the event already occurred. In my maybe_finish_animations function, I delay it by 10ms to give other listeners a chance to respond (in case it was really the listener that loaded it) and then does a simple check based on the classes to see if there is anything that is left needing to be animated. If so, it dispatches the load event on window again.

    const aurise_neve = {
    init: function() {
    if (document.readyState === 'complete') {
    aurise_neve.maybe_finish_animations();
    } else {
    window.addEventListener('load', aurise_neve.maybe_finish_animations);
    }
    },
    maybe_finish_animations: function() {
    setTimeout(() => {
    let animated = document.querySelectorAll('.animated').length,
    finished = document.querySelectorAll('.o-anim-ready').length,
    allow = animated > 0 && finished === 0;
    if (allow) {
    // Dispatch the load event manually
    window.dispatchEvent(new CustomEvent('load'));
    }
    }, 10);
    }
    };
    aurise_neve.init();

    Actual Solution: I’d like to request that you update your JS to listen to the document’s ready state to determine if it needs to run immediately or add the listener.

    I can see that calls to wp_enqueue_script() sets the fifth parameter to boolean true to place it in the footer, but my performance modifications also sets the strategy to defer. Out of the box, I understand your script wouldn’t need changes but when defer or async is applied, it could, so this isn’t necessarily a bug, but just a request ?? Maybe even make it a custom event or a direct function I can call instead of triggering the load event. So far, there hasn’t been an issue with it being triggered again but it doesn’t feel like the “best practices” option.

    Thanks!

    The page I need help with: [log in to see the link]

Viewing 1 replies (of 1 total)
  • Plugin Support Kush

    (@kushnamdev)

    Hi @tessawatkinsllc,

    Thank you for contacting us and sorry for the delay in reply.

    I have reviewed the information shared by you and tried to test this issue on our end, but the block animations work fine on both Edge browsers and mobile devices.

    Is it possible this could be a cache issue at your end? Could you please try to clear your cache and check again (if you are still facing this issue)?

    I am looking forward to your reply, thank you!

Viewing 1 replies (of 1 total)
  • You must be logged in to reply to this topic.