IE10 issue: views[] array inside renderCollection loses el.innerHTML about human-view HOT 11 OPEN

@CNovakCAA can you show me the code in your app where you use renderCollection and describe the issue you're having?

from human-view.

I'd like to get to the root of the problem, but as another bandaid, I'm curious if something like lodash's clonedeep would work? I believe it handles circular references.

from human-view.

Line 197 in ./clientapp/pages/options.js in phonesheet5 development branch calls collection.create(), which in turn calls reRender(), which then calls addView().

The result should be a new call status being generated then added to the collection and rendered in the view, but in IE10, all statuses disappear as their view.el.innerHTML is set to an empty string in reRender().

from human-view.

So in IE10 you still have a root element for each call status in the container element, right? But it's empty, is that what you're saying?

from human-view.

the tests all pass on IE10: https://cloudup.com/cjD9YGronzk

Going to try to write a test for the specific problem you're having, though.

from human-view.

That was a weird one.

Was able to reproduce what you described in the test suite and then make a minor syntax change that fixed it.

Apparently in IE10 when you've got a parent element with children and set innerHTML = ""; on the parent to clear it. It appears that some IE engineer decided that as a developer when I did that, it also means that I want to set .innerHTML of all the child nodes to empty string as well, rather than just de-referencing them.

Anyway, when I loop through the views and remove them manually it works.

from human-view.

👍

from human-view.

@HenrikJoreteg, I actually think the IE10 behavior is the correct one. The view that was being stored in the views[] array was an object, passed by reference, into any array (essentially another variable). That means changes to the original object would affect the referenced one in the array, which is the correct implementation. I think this is less about children of a DOM element being affected by innerHTML = "", and more about how JavaScript passes objects by ref, not value.

IMO, the other browsers got it wrong, IE10 was doing the right thing, surprisingly.

from human-view.

Yes, the views are passed by reference, as all objects are.

But i'm setting .innerHTML of the parent container, why would that have anything to do with the elements within it at all?

There is no such thing as a copy or clone going on anywhere here. Each view in views array is a single object in memory. It doesn't matter if i put that same view into 50 different arrays, it's not being copied ever. So I don't follow your logic.

from human-view.

I agree, there is no copy / clone going on. I thought looping addView() retrieved the view from the views[] array, and you were expecting to retrieve the innerHTML from that. But, IE10 cleared out the view.el.innerHTML in the array when the innerHTML was cleared from the original view object.

You're saying containerEl inside the renderCollection() fn is the container for the view of the collection (top level view)? And when you pass {containerEl: container} into view.render() (line 256), that ref is telling the sub-view that "container" is its parent view's element?

In that case, no, IE10 shouldn't empty the sub-views' innerHTML when you clear the parent view's innerHTML. Seems like jQuery ran into this same bug 2 years ago:

http://bugs.jquery.com/ticket/11473

Microsoft's answer to jQuery was "this won't be fixed in IE10 because it's too much work."

from human-view.

Ah, right, the variable naming was confusing. Yeah, i'm talking about the parent container that holds all the rendered views for the collection.

Anyway, seems all is well.

published latest as 1.6.5

from human-view.