Possible issue with ember-source 3.16.2

[brunoocasali]

Hey people! (thanks for the awesome work)

I hate open issues and not pull requests, but this time I must to report...
I have a ember octane version app, and my last upgrade to ember-source 3.16.2 all the infinity scrolls stopped working...

When I reach to bottom, I see the next page with right params but no data are appended to the list and the spinner never stops to spin!

my app versions are:
ember-source 3.16.2 (in 3.16.1 works well)
ember-infinity 2.0.2 (i could not upgrade to the latest because issue #417)
ember-data 3.14

I have a pretty default configuration + a customized .hbs template of infinity-loader.

{{#if hasBlock}}
  {{yield this.infinityModelContent}}
{{else}}
  {{#if this.isDoneLoading}}
    {{#if (and (eq this.infinityModel.length 0) this.infinityModel.reachedInfinity) }}
      <div class="center-column margin-t__24">
        <Empty />
      </div>
    {{/if}}
  {{else}}
    <SpinnerLoading />
  {{/if}}
{{/if}}

Feel free to request me more information, I would love to contribute if I could.

Thanks again!

[snewcomer]

#419

Looks like we do have an issue. Will have to look into this travis CI test failure on 3.16.2...

[GreatWizard]

I have the same bug behavior and my project i'm still on v1.4.9

[snewcomer]

My initial inclination is updating an ArrayProxy's content and that not propagating in the template. Still digging....

[snewcomer]

ref Emberjs issue - emberjs/ember.js#18750

[snewcomer]

A fix has been merged and perhaps will be backported to 3.16 or will see it in 3.17!

emberjs/ember.js#18770

[deanylev]

Unfortunately this does not seem to be fully fixed. We are facing an issue where the second page of results does not load when scrolling down unless you scroll up and back down again. Does not happen on ember-source 3.16.1, but happens on 3.16.2, 3.16.6, and 3.16.8 from what I've tested.

EDIT: This was actually caused by a couple of observers in our code. It seems the fix for ArrayProxy in 3.16.6 is not equivalent to how it behaved in 3.16.1 and earlier. Worked around it by wrapping their callbacks in Ember.run.next.