Skilltech

@Warren_A I've put the opening divs in my header.php and the closing divs in footer.php, assuming you're building your own theme as I am. <!-- opening tags in header.php --> <div id="smooth-wrapper"> <div id="smooth-content"> <!-- closing tags in footer.php --> </div><!-- #smooth-content --> </div><!-- #smooth-wrapper --> <!-- Opening tags go at the bottom of the header.php TIP: any "position: fixed;" elements you should put outside these tags (before opening them). Closing tags go right before <?php wp_footer(); ?> and </body> closing tag. And your overall HTML structure should be correct i.e. no unclosed divs or too many closed divs by mistake. -->

Thanks! It did remove the error. But the "dropdown options" element is now behaving wacky i.e. goes counter to scroll direction (when I set #smooth-content as dropdownParent). So I'll have to stick with my patch of forcing it to close on scroll.

Woocommerce uses a modified version of select2, called selectWoo. And when "dropdownParent" is used, it throws an error "Uncaught TypeError: l.css is not a function".

I tried it of course, it's not working for me.

For anyone using select2 with ScrollSmoother, you can force the dropdown close on scroll like so: /** * Initialize Select2 */ var targetForSelect2 = 'select'; // we'll reuse the selector $( targetForSelect2 ).select2({ // your options }); // on window scroll, close any open select2 dropdowns $(window).scroll(function() { var select2Dropdown = $( targetForSelect2 ); if (select2Dropdown.length) { select2Dropdown.select2( 'close' ); } });

I'm trying to avoid creating a codepen since this is a hugely used library. https://select2.org/ Have you heard of WooCommerce? It uses select2, among others. The point of my thread is not to deal with my specific issue but to bring it to the devs' attention since this is related to ALL WordPress themes which use Woocommerce aka 99.99% Ecommerce WordPress sites.

ScrollSmoother has buggy behavior with Select2. To replicate: integrate select2, initialize it on any "select" element, click the dropdown and scroll while the dropdown is open see the dropdown options detach from the dropdown itself

Thanks again.

And what would the code look like then? Will you fix my fix with your fix and share a snippet? ? Thanks

It is inside that iframe and only inside that iframe. I described it in detail above. The thing is that when editing, you are on the editor page, and "final" page is in the iframe, BUT it's updating in real-time, so they are connected with some JS magic. Or elementor is building an instance of that final page but it's not really the actual page and that particular instance is somehow being affected by the editor page. I was talking about ScrollSmoother, not Trigger. But I might as well refresh ScrollTrigger, it's a good idea. ScrollSmoother could also benefit from its own .refresh() method. Anyway, the patch is now doing its job. So, until Elementor guys fix that conflict, ScrollTrigger/GSAP users won't be very happy.

I fixed that as well. Here's the code: var elem = $( "#smooth-content" )[0]; let resizeObserver = new ResizeObserver(() => { smoother.kill(); smoother = ScrollSmoother.create({ smooth: 2, // seconds it takes to "catch up" to native scroll position effects: true // look for data-speed and data-lag attributes on elements and animate accordingly }); }); resizeObserver.observe(elem);

As I've said, I'm working with a fully working code (with gsap + ScrollSmoother installed) with 0 errors. Yes I wouldn't say "only" for previewing when that's where people need to build their website. Otherwise they'd be blind or crippled. Doesn't help. No change with ScrollTrigger. UPDATE 3: I also tried .detach() and (re) .attach() of the iframe and that removes the issue as well (again, with doubled warnings etc. in the console). Question: can I restart ScrollSmoother when #smooth-content div's height changes? I think it also plays a part in Elementor. When I drop a new tall widget (like a full-height section)(widget = Elementor editor/page builder elements), I see that the scrolling is working but not going all the way down (as though the ScrollSmoother is not aware of the new height).

With 5+ million active installations I think Elementor might deserve a test run. The real number is probably much higher, 5+ million is just a cap number on wordpress .org To test, all you'd need is WordPress running (free) and Elementor running (also free). I know that, and it looks pretty illegal. As for smooth: 0, I alredy tried and wrote it down. That's not really acceptable. UPDATE 2: With further testing, when I wrap the <iframe> with a single generic <div>, that also fixes the scrolling (but also doubles the warnings and erros in the console).

UPDATE: It's still a huge issue but I've shamelessly patched it. Since Elementor's editor is iframing the final page which is being edited, your code for some reason stops working but just for the heck of it I tried wrapping the, get this, iframe in #smooth-wrapper and #smooth-content and it worked. I guess your JS is somehow breaking out of the iframe??? Since I have access to the Editor page, which is the parent of the iframe, I waited for it to generate the iframe and then did the wrapping. Here is the code if someone needs to patch it until the issue is fixed (I also noticed that console warnings and errors are now doubled but everything else's running fine). jQuery(document).ready(function($) { "use strict"; function patchGSAPElementorConflict() { var i = 0; var checkIfIframeIsLoaded = setInterval(function() { if ( $( '#elementor-preview-iframe' ).hasClass( 'iframe-loaded' ) ) { // addClass (below) performed successfully, exit! window.clearInterval(checkIfIframeIsLoaded); } else if (++i === 50) { // Still no target to addClass to after 15 seconds, something's wrong with page load, exit! window.clearInterval(checkIfIframeIsLoaded); } else { /** * Target found */ // #1 Adding the class to use to clearInterval // #2 Making the iframe fullheight (wrapping it with #smooth-wrapper below would colapse it otherwise) $( '#elementor-preview-iframe' ).addClass( 'iframe-loaded' ).css( 'min-height', '100vh' ); // wrapping the iframe with smooth-wrapper and smooth-content $( '#elementor-preview-iframe' ).wrap( '<div id="smooth-wrapper" class="pushable-content"></div>' ); $( '#smooth-wrapper' ).wrap( '<div id="smooth-content"></div>' ); } }, 300); } window.onload = () => { patchGSAPElementorConflict(); }; });

In WordPress, in Elementor's editor, when ScrollSmoother is initiated, the page cannot be scrolled. That is a HUGE problem. Basically renders ScrollSmoother useles in the most used WordPress plugin. If you have some pull with them you should press them to fix it or if you can do something on your end that would also work. CodePen is inapplicable. You need WordPress installed, then Elementor plugin and then edit the page using "Edit with Elementor". I have GSAP, ScrollTrigger, ScrollSmoother and ScrollToPlugin running. And of course smooth-wrapper and smooth-content. I'm "wordpressing" a HTML website which works perfectly fine so there are no bugs. Also, the final published page in WordPress works fine. The issue is ONLY present when the page is being edited with Elementor. When "smooth" is changed to zero, the page becomes scrollable but none of the scrollTrigger animations work. gsap.registerPlugin(ScrollTrigger, ScrollSmoother); let smoother = ScrollSmoother.create({ smooth: 2, // seconds it takes to "catch up" to native scroll position effects: true // look for data-speed and data-lag attributes on elements and animate accordingly });