Text imput fails to load bug

[lovegushwa]

@Giorgio-Olivero @abusedmedia @michellenebiolo

We found a bug when hitting the "got it" button during the first on boarding screen animation. @ScottDowne will add details here.

[ScottDowne]

I can make this happen in firefox 45 on windows 10 and el capitan

Steps to reproduce:

1. Open http://el.s.todo.to.it/cryptoloji/1135 in a private tab
2. Click "Let's get going" as soon as you can
3. Click "Got it" as soon as you can

Expected: Three panels, and the left can accept input and says "Write your message here." Actual: Left panel doesn't display "Write your message here." and visually doesn't accept input. If you type anyway, and reload, it'll show whatever you typed.

It doesn't do this while in a mobile view.

[ScottDowne]

Here is a screen shot.

[abusedmedia]

Hi @ScottDowne We are currently testing on the built version posted here: http://todotoit.github.io/codemoji/

Can you confirm the same issue on that version?

many thanks

[ScottDowne]

@abusedmedia Yup, I can confirm same issue happening with http://todotoit.github.io/codemoji/

[abusedmedia]

We've investigated a lot and we've ended up on a workaround (delaying the fade-in of the 'got it' button) since we cannot fix it in a proper way without making core changes on the app.

The reason of the issue, apparently, rely on the combination of a Firefox known bug with how the animation library we are using handles that bug. Here the reference of our finding:

https://bugzilla.mozilla.org/show_bug.cgi?id=612118 http://greensock.com/forums/topic/11143-ns-error-failure-with-tweenmax-svg-and-firefox/

You can test the patch on the same current public url http://todotoit.github.io/codemoji/

[ScottDowne]

Hey @abusedmedia

That helps a bit, but still kinda happening if I click "got it" during step two.

Based on the links above you provided, sounds like the issue is using tweenlite on an svg that's not in the DOM, correct? If so, i'm curious which svg? Possible to add it to the DOM and hide it while applying the animation? Thoughts?

[abusedmedia]

I see, we need to figure out a better workaround.

About your question, all the DOM elements are present on app at loaded time. There are not any DOM manipulations at run-time (in terms of adding/removing nodes) but only CSS props transformation through TweenLite.

Our suspect is that Firefox throw an error trying to calculate the getBBox of a svg element that exists in the DOM but is invisible (opacity:0 or display:none) at particular time. It looks like Firefox needs the rendered element (that means visible) in order to get the BBox.

Another solution could be to patch TweenLite in order to avoid the js break, which is the final (and visible) issue. Not ease since we should mess into that big codebase...

[ScottDowne]

Does height/width 0 overflow hidden do the trick and not trigger the bug?

[abusedmedia]

Hi @ScottDowne I should have fixed that bug cleaning up TweenLite instances explicitly on state changes. Can you confirm? Thanks

[ScottDowne]

Solid! :tada: