FIX: Consistently show history modal when clicking edit notifications (PR #13912)

Currently when a user clicks on an edit notification, we use appEvents to notify the topics controller that it should open up the history modal for the edited post and the appEvents callback opens up the history modal in the next Ember runloop (by scheduling an afterRender callback).

There are 2 problems with this implementation:

  1. the callbacks are fired/executed too early and if the post has never been loaded from the server (i.e. not in cache), we will not get a modal history because the method that shows the modal returns if it can’t find the post:
  1. when clicking an edit notification from a non-topic page, you’re redirected to the topic page that contains the edited post and you’ll see the history modal briefly and it’ll be closed immediately. The reason for this is because we attempt to show the history modal before the route transition finishes completely, and we have cleanup code in initializers/page-tracking.js that’s called after every transition and it does several things one of which is closing any open modals.

The fix in this PR defers showing the history modal until posts are loaded (whether fresh or cached). It works by storing some bits of information (topic id, post number, revision number) whenever the user clicks on an edit notification, and when the user is redirected to the topic (or scrolled to the edited post if they’re already in the topic), the post stream model checks if we have stored information of an edit notification and requests the history modal to be shown by the topics controller.


This seems like a fine solution, however we should add a resetLastEditNotification() method (or similar name) that will set it back to null. Then add it to the test suite between tests to avoid leaking state.