Restore scroll position after transition, via history.back(), resolves

[GCheung55]

Below is a BDD description of the issue.

• Given routes A and B

• And route A has a model method that returns a promise from store.findAll method

• And the promise resolves with an empty records array

• When a user transitions from route A to route B

• And the user uses the browser “back” button, or executes history.back method, to navigate back to route A

• Then the Ember app begins to transition to route A, executing themodelmethod

• And rendering route A is blocked, waiting for the promise, returned by the model method, to resolve

• And...
  Expected:
  Restoring scroll position waits till after rendering of route A is unblocked by the promise, returned by the model method, resolves.

  Actual:
  Restoring scroll position occurs before rendering of route A occurs, before the promise, returned by the model method, resolves.

Restoring scroll position before transitioning causes bad and unexpected UX.

The scrollWhenIdle and scrollWhenAfterRender options do not address the issue.

[snewcomer]

The only state we hook into is when Ember notifies us of render or afterRender, which is when we render our scroll callback. If the data store has records, it resolves immediately with the records and may background reload. Do you have an example repo where this is not working? I would have expected at least scrollWhenAfterRender to work...

[jleja]

I've recently come across this issue, but seeing this with lazy-loaded page elements (not using Ember Data in my particular project). What I've found is that when tryScrollRecursively() is able to see that the document height is equal or greater to the scroll position, that it sets the scrollHash values. But the page in the browser may not reflect the height yet as the components I'm trying to scroll to aren't painted to the page.

Wrapping that fn.call() line in a run.later() with a slight delay (using 1000 for now in my project) makes the scroll behavior more stable. Not to say that that's the best solution, but it works for now. (Note that run.later() will always assume that it should run, but incorporating ember-lifeline's runTask() is a bit more tricky.)