Conflicts with MooTools implementation of window.getSize()

[Bilge]

MooTools implements a version of window.getSize that returns the window dimensions when passed no parameters. Loading this library after MooTools causes it to overwrite MooTool's implementation of window.getSize and any scripts that rely on it to fail.

---

From @desandro:

+1 this issue if you would like to see it resolved.

[nicbell]

Just had the same issue with a Masonry build which depends on this lib. Did a find replace in the build "getSize" with "getSize_FixMe" so it wouldn't conflict with MooTools. 👎

[desandro]

Well, it sounds like I have made a huge mistake 😭 Like @nicbell mentions, one way to get around it, is to do a fide/replace. Or you can use RequireJS, so that modules are loaded without any namespace conflicts.

[chameron]

@nicbell do you try it ? i have tried do same thing and get other error :(

[fritzmg]

The fix works (replacing all instances of getSize with something else, like getSize_FIXME). However, it would be nice if this finally fixed in the source of Masonry.js, it has been far over a year now since it was first reported ;).

Since I am using the Contao CMS I find myself confronted with this problem frequently whenever I want to use Masonry.js there, since a lot of other Contao Extensions rely on MooTools.

[Bilge]

I'm pretty sure @desandro doesn't give a single shit about MooTools at this point.

[hamidrezabstn]

please clear out how to fix this problem!!! i am a user not a professional! i've tried find/replace trick but it did not work ! please HHHHHHHHHHHHEEEEEEEEEEELLLLLLLLLLLPPPPPPPPPPPP!!!

[danyj]

well , no matter where the discussion is , 2 years after the report of this bug it is not changed, I took @nicbell advice and fixed it but you can just name your getSize something else and close this issue.

[Bilge]

I already tried closing this once but Desandro was like, NIET.

[fritzmg]

Well, why close it, when it's not resolved yet?

[desandro]

This issue is still open because it is not resolved. getSize is a lower-level library used in many of my other libraries. I prefer to keep the browser global name as getSize rather than changing it for several reasons:

• Likely backwards compatibility issues, requiring updates to
• After changing the browser global from window.getSize, There'd be a name mis-match with the project on GitHub desandro/get-size and the npm library get-size. It's either confusing, or I have to switch over names
• This issue has not gained much public attention

I do give several shits about Moo Tools. I also care about other libraries. I am considering getSize's interoperability within the huge front-end development ecosystem. As this issue has only had a handful of replies in 2 years, this issue's solution hasn't warranted priority over maintaining the projects current compatibility.

[mthomsonnz]

Currently I'm also having a problem with this issue. Within the joomla cms ecosystem (5 million+ sites) the mootools library is still used a lot, and any template that implements isotope will clash with any joomla extension that uses mootools, so +1 for please fix this! Thanks.

[websperations]

I am also having this issue with Joomla. I am using a commercial template on a site upgrade and now our existing Ignite Photo Gallery lightbox functionality is broken. Ignite Gallery developers isolated this problem and basically said they cannot address the issue as it's a js file.

[AbcAeffchen]

👍 for fixing this issue

[AnrietteC]

Thanks nicbell! I hate having to edit plugins like this, but it breaks some K2 front-end editing.

[webmasterMeyers]

+1 on the issue. I just loaded MooTools after Masonry (which contains this same code) and my MooTools dependent stuff works fine.

[desandro]

Putting this one to rest. If you are using MooTools and a Metafizzy plugin in 2022, you are incredible. Goodnight.