I wish I could give you really specific feedback, but honestly I just get this pretty randomly in the javascript console.
Uncaught TypeError: Cannot read property 'tweensContainer' of undefined
It doesn't seem to break anything.
It's hard to pinpoint what causes it.
I don't know what the heck a tweensContainer is...lol
You likely have some scripts trying to run on null objects. In any case, I don't think this is a materialize problem.
That is most likely an issue with Velocity working on elements that have been removed from the DOM.
Same problem for me.
Not everytime but it appends on some Toast disapearing.
Here in the minified code :
if("start"===C){var E;g(f).tweensContainer
Probably the object is removed from other scripts I'm using (backbone, handlebars, jquery...) at some point but a test of "g(f)" should correct the problem for every situation.
I also get this error when opening modals, but only sporadically.
I found a fix for my case. The tweensContainer error is coming from Velocity that Materialize uses for animation. The error happens if you remove an element that is being animated before the animation is finished. So I called .velocity("finish").velocity("stop") on the element being animated before removing it. Here's my example code with the "stop" bits added:
$ ->
$.rails.allowAction = (link) ->
return true unless link.attr('data-confirm')
$.rails.showConfirmDialog(link) # look bellow for implementations
false # always stops the action since code runs asynchronously
$.rails.confirmed = (link) ->
link.removeAttr('data-confirm')
$('#confirmationDialog').velocity("finish").velocity("stop")
$('#confirmationDialog').remove()
link.trigger('click.rails')
# Materialize
$.rails.showConfirmDialog = (link) ->
$('#confirmationDialog').velocity("finish").velocity("stop")
$('#confirmationDialog').remove()
message = link.attr 'data-confirm'
cancel = link.attr('data-cancel') || 'cancel'
ok = link.attr('data-ok' ) || 'ok'
html = """
<div id="confirmationDialog" class="modal">
<div class="modal-content">
<p>#{message}</p>
</div>
<div class="modal-footer">
<a href="#!" class=" modal-action modal-close waves-effect waves-green btn-flat">#{cancel}</a>
<a href="#!" class=" modal-action modal-close waves-effect waves-green btn confirm ok-confimation-button">#{ok}</a>
</div>
</div>
"""
$('body').append(html)
$("#confirmationDialog").openModal
ready: ->
$('#confirmationDialog .confirm').on 'click', ->
$.rails.confirmed(link)
$('#confirmationDialog .modal-close').on 'click', ->
$('#confirmationDialog').remove()
$(".ok-confimation-button").focus()
This issue should be reopened. This is a materialize bug. The solution proposed by sfcgeorge above fixes this. Since materialize uses velocity internally, users shouldn't have to call velocity explicitly. Materialize should be calling $(element).velocity("finish").velocity("stop") before removing animated elements.
I have seen this with not only dialogs, but also tooltips and toasts.
Yeah it sporadically causes our integration tests to fail which is a pain, so I've wrapped tests to disable velocity... and jQuery animations, but there are still issues occasionally.
Is this going to be re opened / addressed? I still have this issue and have no way of removing it without saving and editing the file to make sure g(f) isn't undefined. I'm not really even sure what this function is doing as it doesn't seem to break my page at all in its functionality.
I do not have any explicit DOM objects being removed so this explicit velocity call doesn't help me.
Please re-open... I don't know what velocity is, only materialize. I'm getting this error sporadically.
same here. Please re-open
Ditto, please re-open this. I get this error in my app when there are animations and elements are being removed.
All the way in 2018, still asking to be reopened.
This was an error message created by velocity which was removed in 1.0 alpha so this issue is deprecated
The version installed when a user runs npm i --save materialize-css is 0.100.2 ... Can this be reopened so that those that do install (for instance myself today) do not take this bug with them. Unfortunately after review I had to remove the package because this bug breaks other packages that use tween animations.
What is stopping a fix being implemented in the current release? I believe there is a solution posted above, do you guys accept PR's?
@shardy613 Please read my comment above
Hey,
I did read your comment, that said the bug is still in the version that is installed via npm i --save materialize-css (please see my comment about installed versions above). What we are asking is for a fix in the current version, not for a fix in an unreleased version that we do not get when running npm install materialize-css.
This is something that would need to be fixed in the Velocity library, which may or may not happen: https://github.com/julianshapiro/velocity/issues/305
Either way, we will not be releasing additional fixes for 0.100.2, please look into upgrading to 1.0.0-beta.
@shardy613 if you want to install 1.0.0-beta you may use npm i --save [email protected] per the version list (click "22 versions" near the top-right) and this SO thread on installing a specific version from NPM.
Thanks. Users can also user npm install --save materialze-css@next for a nightly release.
@shardy613 I added a pull request (#5782) which adds that command to the readme. Also, @next is equivalent to the highest version number, so it (for now) is identical to @1.0.0-beta
Just to confirm, it is advised to use the 1.0.0-beta version in production environments?
While there are still some things we need to iron out, we do believe that 1.0.0-beta is in a more stable state than the old version (0.100.2), purely from the large number of bugs fixed. In addition, it is easier to use form a developer standpoint, especially inside Single Page apps.
Please refer to the upgrade guide if you are interested in upgrading: https://github.com/Dogfalo/materialize/blob/v1-dev/v1-upgrade-guide.md
Okay, thanks for taking time to confirm.
Cheers.
Wow, I filed this issue 3 years ago yesterday. I'm glad you guys are figuring something out. :-D
happy issueversay :P
Most helpful comment
This issue should be reopened. This is a materialize bug. The solution proposed by sfcgeorge above fixes this. Since materialize uses velocity internally, users shouldn't have to call velocity explicitly. Materialize should be calling
$(element).velocity("finish").velocity("stop")before removing animated elements.I have seen this with not only dialogs, but also tooltips and toasts.