Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
themepunch

GSAP3 vs. Wordpress 5.3 mediaelement.js Conflict

Recommended Posts

Hi Guys,

 

 Testing GSAP3 in the latest Wordpress 5.3 Environment,  loading your latest gsap and enque Wordpress Standard Plugin called mediaelement.js conflicts:  

 

- New Clean standard Wordpress Installation. 
- Load GSAP Library and use wp_enqueue_media(); 

will break the Page with JS failure.

 

mediaelement-and-player.min.js?ver=4.2.13-9993131:7745 Uncaught TypeError: Cannot read property 'userAgent' of undefined
mediaelement-migrate.min.js?ver=5.3:1 Uncaught ReferenceError: mejs is not defined
wp-mediaelement.min.js?ver=5.3:1 Uncaught TypeError: n(...).not(...).filter(...).mediaelementplayer is not a function
 

 

Please try to install a Clean Wordpress and install the Plugin attached (which only load GSAP and use Standard Wordpress Function wp_enqueue_media())
and you will see the issue.

 

Hope this can be fixed.

 

Thanks again and have a great day ! 

 

ThemePunch

 

testpage.zip

  

Share this post


Link to post
Share on other sites

Hey themepunch. 
 

Another user emailed about this issue. He was able to solve it when using Toolset Views and GSAP 3 in WordPress by enqueuing gsap.min.js with a dependency of wp-mediaelement. Does that help?

  • Like 1

Share this post


Link to post
Share on other sites

Good Morning ! 

 

yes, this is a workaround we use also, somehow still don't feel safe.  Would it be possible to take a look into the root of the conflict and check if something else maybe need to be more "sandboxed" in gsap ?   

 

Thanks for all your effort and for the best Tool ever ! We really appreciate your hard work guys ! 

 

Cheers,

 

Krisztian

Share this post


Link to post
Share on other sites

I don't really understand the conflict - it doesn't seem like it's in the GSAP code at all. For example, I don't think there's anything that could generate the error "Uncaught TypeError: Cannot read property 'userAgent' of undefined". Isn't that coming from a different (non-GreenSock) file? Is there some reason you think this is GSAP-related? 

Share this post


Link to post
Share on other sites

Yes, the error comes from the Standard Media plugin from Wordpress, however this happens when GSAP loaded. If we dont load GSAP, or we load GSAP after the media plugin from Wordpress loaded,  the error is not existing.

 

If you download a clean new version from Wordpress and load GSAP and than enqueue the media plugin (wp_enqueue_media(); ) which is standard Wordpress function, you will get the error.   

 

Means GSAP set / change something on a global level which is than not anymore available for the next coming Wordpress standard plugin.  So it is GSAP related.  I sent you in the first message a simple demo plugin which shows the case.  

 

The problem even if i load the GSAP after the mediaplayer, it is not guaranteeed that the next loaded plugin not breaks than.  I hope you understand what i mean ?

 

If you need more details, please let me know,

 

Krisztian 

Share this post


Link to post
Share on other sites

I don't use php or wp. Can you explain in JavaScript terms what is happening? What does enqueue do? Does it concatenate files?

 

It seems like you should be able to get the error by just loading the files in normal web page, but I can't reproduce an error that way. Maybe because I don't know enqueue is doing, or how the scripts are being loaded.

 

The only thing I can think of is this.

 

1487306154_Annotation2019-11-22064131.png.89771c97f01006128d75741224897204.png

 

It looks like mediaelement uses a object on the window called default. gsap also creates a default object on the window. I don't know if that is the problem, but if it is, then gsap would probably need to get rid of default exports in the modules, which would probably be a breaking change. Or you could tell the mediaelement people not to use the default object. I'm sure there are other libraries that also create a default object due to the way they are built.

 

Or use modules, which don't use globals.

 

Share this post


Link to post
Share on other sites

I totally agree with you that this part might be a problem caused by WordPress but since WordPress is used by 35% of all websites worldwide currently I thought it might be worth checking if there is a workaround. Otherwise Greensock would run potentially into trouble on millions of websites. Please correct me if I am wrong here! 

 

Share this post


Link to post
Share on other sites

All I was showing was the possible conflict in that library.

 

But it would be better if you could show how to reproduce the error in just a normal web page without having to use wordpress. At the end of the day, it's just JavaScript, so the error should be reproducible.

 

I don't get any errors loading mediaelement and gsap, so maybe I'm missing something here.

See the Pen 152bd9c5d4b2c62887b4f5b68415a9a2 by osublake (@osublake) on CodePen

 

 

  • Like 1

Share this post


Link to post
Share on other sites

See the Pen ZEEZKmR by themepunch (@themepunch) on CodePen

 

Loading the two scripts shows the error.  This mediaelement.js is loaded almost in every Wordpress installation in the backend.

Share this post


Link to post
Share on other sites

Thank you. Now it's easier to troubleshoot.

Share this post


Link to post
Share on other sites
2 hours ago, OSUblake said:

The only thing I can think of is this.

 

1487306154_Annotation2019-11-22064131.png.89771c97f01006128d75741224897204.png

 

 

Just like I pointed out, errors will start right there because it's using default.

1231113826_Annotation2019-11-22090248.png.0d7d16bb93a8932979944ce24a2246b0.png

 

 

It errors using simple umd code. No gsap here.

See the Pen da26401ff624affec9128c32c033188b by osublake (@osublake) on CodePen

 

 

Maybe raise an issue with mediaelement.

 

 

 

  • Like 2

Share this post


Link to post
Share on other sites
29 minutes ago, ZachSaucier said:

I'll do it.

 

Cool!

 

For some reason, this line of code in my demo causes it to error. 

 

Object.defineProperty(exports, '__esModule', { value: true });

 

It's seems to be conflicting with their code somehow. 

https://github.com/mediaelement/mediaelement/blob/5bc2965eaa0a0e97127c4444085244fc6d6f9f9f/build/mediaelement-and-player.js#L7725

 

Object.defineProperty(exports, "__esModule", {
	value: true
});
exports.cancelFullScreen = exports.requestFullScreen = exports.isFullScreen = exports.FULLSCREEN_EVENT_NAME = exports.HAS_NATIVE_FULLSCREEN_ENABLED = exports.HAS_TRUE_NATIVE_FULLSCREEN = exports.HAS_IOS_FULLSCREEN = exports.HAS_MS_NATIVE_FULLSCREEN = exports.HAS_MOZ_NATIVE_FULLSCREEN = exports.HAS_WEBKIT_NATIVE_FULLSCREEN = exports.HAS_NATIVE_FULLSCREEN = exports.SUPPORTS_NATIVE_HLS = exports.SUPPORT_PASSIVE_EVENT = exports.SUPPORT_POINTER_EVENTS = exports.HAS_MSE = exports.IS_STOCK_ANDROID = exports.IS_SAFARI = exports.IS_FIREFOX = exports.IS_CHROME = exports.IS_EDGE = exports.IS_IE = exports.IS_ANDROID = exports.IS_IOS = exports.IS_IPOD = exports.IS_IPHONE = exports.IS_IPAD = exports.UA = exports.NAV = undefined;

var _window = _dereq_(3);

var _window2 = _interopRequireDefault(_window);

var _document = _dereq_(2);

var _document2 = _interopRequireDefault(_document);

var _mejs = _dereq_(9);

var _mejs2 = _interopRequireDefault(_mejs);

function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }

var NAV = exports.NAV = _window2.default.navigator;
var UA = exports.UA = NAV.userAgent.toLowerCase();

 

Share this post


Link to post
Share on other sites

Thanks for all the detective work, @OSUblake. For the record, GSAP itself doesn't create any "default" object on the window - it looks like that's something Rollup does in the packaging process for the UMD files. Do you think that's an important piece that folks who use the UMD package would rely on? Maybe it's something that can be stripped out after Rollup does its thing. But either way, it sure does sound like that mediaelement library has some vulnerable code, as GSAP certainly isn't the only library that'd ever have a default export that could be added to the window, so ideally they'd make changes on their end. 

Share this post


Link to post
Share on other sites
25 minutes ago, GreenSock said:

For the record, GSAP itself doesn't create any "default" object on the window - it looks like that's something Rollup does in the packaging process for the UMD files.

 

Yeah, that's definitely done by rollup. That's why I thought the default object it creates might have been the culprit. But then I commented out the default part that rollup creates, and the problem still existed. Then I removed all the gsap code, and the problem still existed. So creating a default object isn't the the main issue.

 

I think it's this part of their code, which I think is done by browserify. Because __esModule is already set on the window, the _interopRequireDefault function returns obj, but the code is expecting it to return { default: obj }.

 

var _window2 = _interopRequireDefault(_window);

function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }

var NAV = exports.NAV = _window2.default.navigator;

 

  • Like 2

Share this post


Link to post
Share on other sites

Hi Guys ! Really appreciate all your effort so far and happy that you dive into this.  What my (limited) understanding / worry is, that even Mediaelement fix the issue their side,  it would not hit the few hundred million installations which already exiting and running outside the world, means GSAP would break the site so far its loaded before the mediaelement libraries (even if it is not GSAPs fault).  I don't think that all the WP folk will just make an update that quick. 

 

So if you have a solution / workaround here without relaying on mediaelement / wp, i think you are on the safe side.

 

Thank you again and wish you a great weekend

Krisztian

  • Like 1

Share this post


Link to post
Share on other sites
10 minutes ago, themepunch said:

So if you have a solution / workaround here without relaying on mediaelement / wp, i think you are on the safe side.

Agreed. If we could add a workaround for the 3.0.2 release I think that would be a good idea. 

 

Obviously I hope they fix it on their side and we can encourage users to enqueue mediaelement as a dependency for GSAP as well but it'd be safe to work around it in GSAP if we can to keep conflict to a minimum.

  • Like 2

Share this post


Link to post
Share on other sites

Yeah just like Zack advised in his last post..

 

You should enqueue the  GSAP script file that in that wp_enqueue_script() method.
 

So you can add mediaelements.js as a dependency for GSAP.

 

https://developer.wordpress.org/reference/functions/wp_enqueue_script/

 

You can add dependencies for the 3rd parameter.

  • $deps -  array(Optional)
    An array of registered script handles this script depends on.

Plus you can also tell it to load in the footer as the last parameter..

  • $in_footer - (bool) (Optional)
    Whether to enqueue the script before </body> instead of in the <head>.
    Default 'false'.
    Default value: false

Happy Tweening :)

  • Like 2

Share this post


Link to post
Share on other sites

The only solution right now is to make sure mediaelement loads before gsap. I guess that's what you're talking about with having it a dependency?

 

To fix this problem, @GreenSock would probably have to manually change all the dist files, and I'm not 100% sure this is a good solution as hasn't been tested.

 

(function (global, factory) {
   typeof exports === 'object' && typeof module !== 'undefined' ? factory(exports) :
   typeof define === 'function' && define.amd ? define(['exports'], factory) :
  (global = global || self, factory(global.window = global.window || {}, true));
  }(this, function(exports, isBrowser) { 'use strict';   
                                       
    if (!isBrowser) {
      Object.defineProperty(exports, '__esModule', { value: true });
    }
  }));

 

No errors, but quite an icky workaround having to manually do this to every file.

 

See the Pen a215b51251ab29bd809c689e43ba7c9b by osublake (@osublake) on CodePen

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Yeah, this is pretty sticky. Blake, what if we wrapped it like this?: 

if (typeof(window) === "undefined" || window !== exports) {
      Object.defineProperty(exports, '__esModule', { value: true });
}

But that'd also mean that GSAP files wouldn't export a default if a window is detected in the environment. Seems odd, of course, and I'm not sure how many people that'd actually bite. Like if they require("gsap") for example. Thoughts? 

Share this post


Link to post
Share on other sites

Yeah, you could try that. Just be ready to push out another patch in case that creates issues for people. It seemed to work in what little testing I did, but I'm really unsure of what the implications might be.

 

Also, I noticed that some of your file header comments are missing in a few of the files like dist/Draggable. Didn't check all the files.

/*!
 * Draggable 3.0.0
 * https://greensock.com
 *
 * @license Copyright 2008-2019, GreenSock. All rights reserved.
 * Subject to the terms at https://greensock.com/standard-license or for
 * Club GreenSock members, the agreement issued with that membership.
 * @author: Jack Doyle, jack@greensock.com
 */

 

And shouldn't the version match the package version? You could probably get rollup to do all that for you.

  • Like 1

Share this post


Link to post
Share on other sites
23 hours ago, OSUblake said:

Also, I noticed that some of your file header comments are missing in a few of the files like dist/Draggable. Didn't check all the files.

Yeah, it's super weird - rollup drops the comments from that one file. I've literally copied and pasted the exact same blurb from other files and it doesn't matter - the Rollup plugin doesn't like something about that file I guess. No errors or anything - it just drops the comments. But I'm switching to a different plugin and it's working fine now. 

 

23 hours ago, OSUblake said:

And shouldn't the version match the package version? You could probably get rollup to do all that for you.

Honestly I was on the fence about that. Originally I figured I shouldn't update the version numbers on files that had zero changes to them...but the more I think about it, the more appropriate it seems to just make everything match version numbers across the board regardless of which files contain changes. Agreed? 

 

I added the workaround to the latest beta: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/gsap-latest-beta.min.js Please let me know if you see any issues with it. 

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, GreenSock said:

the more appropriate it seems to just make everything match version numbers across the board regardless of which files contain changes. Agreed? 

 

Yep.

  • Like 2

Share this post


Link to post
Share on other sites

Hey Guys !  Thanks again for all your effort and help hier ,just like with any other issues we had before. 

 

We all love GreenSock here at ThemePunch and are Big Fun Boys.  

We have to say a Big thank for all the guys like OSUblake, Sahil, ZachSaucier, Jack and all the others who are Hard working for Free !! (Amazing) to give us always a Hand and show us the direction if we lost.

 

 Respect Guys ! 

 

Just keep up the great work and wish you all the best for GSAP3 ! It Rocks !! 

  • Like 3

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×