Doc ready is only called on complete page loads, either when first arriving on the Discourse site, or when you request a hard reload/refresh, or when you move to a page that has little or nothing in common with the page you are viewing.
This is is because Discourse, on occasion, decides that a complete new page isn’t needed, and instead just changes a small part of the page, e.g. topic or category list, and loads this with an Ember ajax call. In such cases, doc ready isn’t fired by the browser page load mechanism because technically, a new ‘page’ hasn’t been loaded.
So your doc ready code below will bind to the .clickable-cell element first time round because an entire new DOM has loaded and the target elements could be found. However, once the body of the page is destroyed and replaced with new contents, the previous binding has disappeared into the ether (even though you can still see the doc ready routine on the page) and the new elements that have been loaded will have no bindings associated with them - e.g. no instructions to notify listeners when something happens.
In saying that, there is nothing to stop the Discourse team manually firing the doc ready event to indicate to client side code_rs_ that their latest async loading is complete. Although, they may not actually know when their code has finished loading the new fragment/view etc, given the nature of the Ember just in time load mechanism.
In the meantime you can track part page loads by hooking into view rendered events and, or page tracker events provided by Discourse/Ember.
See my mention of a similar problem here and possible solutions.
https://meta.discourse.org/t/help-with-client-side-event/39486/2
One other approach would be to render your event code alongside the elements in your views, meaning that whenever these were loaded as part of a whole new page, _or as fragments_ (ajax calls) they'd always fire given they'd always accompany the code to which they were bound to. Problem is, you'd need to ensure that previous event handlers were chained to, which can be complicated and time-consuming for the browser to execute. EDIT: Although I am sure Sam will show you how to do this properly given Ember allows you to bind events on the server without resorting to the hacks I suggested here.