"Maximum call stack size exceeded." with multiple (>42) paper-inputs with error-message

[turboborsuk]

Description

Placing multiple (more than 42) <paper-input> elements with error-message results in "Maximum call stack size exceeded." error in the console. The more - the worse. Not sure if it has something to do with 42 being The Answer. Ref similar: #553

Expected outcome

No errors should occur with a reasonable number of input fields in a page.

Actual outcome

Each error message shows multiple looping sets of calls: " Polymer.flush @flush.html:55 attached @paper-input-addon-behavior.html:24 attached @class.html:225 attached @class.html:223 connectedCallback @legacy-element-mixin.html:98 ensureInstance @dom-if.html:216 render @dom-if.html:150 __renderDebouncer.Polymer.Debouncer.debounce @dom-if.html:116 flush @debounce.html:62 flushDebouncers @flush.html:31 "

Live Demo

http://jsbin.com/nugivejiqi/edit?html,output

Steps to reproduce

• Start fresh polymer 2.0 app.
• Install paper-input
• Place 43 instances of <paper-input error-message="msg"></paper-input>
• Observe error in console

Browsers Affected

• [x] Chrome
• [x] Opera

[43081j]

This may be related to @notwaldorf's change in 5d1c213f.

Haven't quite figured it out yet but the dom-if seems to clash with this flush, so:

• addon calls flush()
• dom-if has no instance yet, so tries to insert addon
• addon attached is called
• addon calls flush()
• etc

[ThibzThibz]

I have the same issue with 42 inputs (or more) and error-message attribute defined.

If less than 42 inputs with error-message attribute : no problem. If more than 42 inputs without error-message attribute : no problem. If more than 42 inputs with error-message attribute, and removing Polymer.dom.flush() call in PaperInputAddonBehavior : no problem.

[notwaldorf]

cc @sorvell

[tlg-tejas]

Any update here?

[notwaldorf]

I can't repro this, and therefore closing. Here's a jsbin that has 100 inputs; the odd ones have error-messages, and are invalid, the even ones don't (so 50 of each) http://output.jsbin.com/qicudij.

Both Chrome and FF are fine with the demo.

[turboborsuk]

Nope, still there in your very bin:

[ghost]

possibly a bug with Chrome? I ran @notwaldorf 's jsbin and got it as well. Tried in incognito, same. Both regular version 65 and beta 66.0.3359.106. It does work in Firefox.

[notwaldorf]

Yup, you're right, errors aplenty. The elements seem to work correctly though. Let me see what @sorvell and @kevinpschaaf think.

[ThibzThibz]

I found a workaround that works for me : overwriting the attached method of PaperInputAddonBehavior to remove Polymer.dom.flush() call. It's maybe not the best solution because that flush surely have some importance, but no more errors !

[notwaldorf]

That line was there for https://github.com/webcomponents/shadydom/issues/96, which looks fixed, so maybe we can remove it altogether. I'll put a PR and run the tests on it and see if it looks fine.

[mattw09]

I'm also hitting this and it took me a while to figure out what was happening until I came across this post. Good catch @turboborsuk! @notwaldorf I've forked the repo and applied your open PR fix for the moment but it'd be nice to have this merged and released soon!

[notwaldorf]

I have a PR open, but unfortunately I don't have the bandwidth to test it and merge it, with IO being next week and my talk for it being not quite done :)

From looking at it, there's nothing functionally broken from this error being in the console, and this bug has been around for ever, so it doesn't seem critical -- as in, it can wait until after IO

[khammami]

@notwaldorf I have the same kind of error but not related to polymer.dom.flush. The error persist even after removing it as suggested above.

this line paper-input-behavior.html#L397 has resulted in too much recursion. Removing it has solved my problem.

UPDATE my issue is related to https://github.com/PolymerElements/paper-input/issues/324 I got this error after upgrading emoji-selector to polymer 2.x https://github.com/khammami/emoji-selector

[mattw09]

@notwaldorf that's fine and there's no rush as I've pointed my dependency to my fork with your fix and it all works but fwiw I do get actual functionality errors without doing this. Best of luck at IO!