DaveLegg

I haven't had a chance to try the new version yet. Just wanted to flag that when testing you'll need to ensure that you're trying to post the reply the first time you've loaded that specific URL in order to encounter the bug. If you've been to the page before, or refresh it, then the issue won't occur

It causes the reply to not show on the page, the editor to not be cleared, and the button to remain disabled - it looks to the user like the reply failed to go through - or is stuck in the process of submitting - on refresh they can then see it

I've literally just been debugging this same issue over at Neowin - we've been experiencing it at least since September. From my testing, the issue only arises if you attempt to reply to a status the first time you load the page you're making the reply on. If you refresh, or navigate away and return, you can reply without issue. Stepping through the JS, I believe I've tracked down the cause of the issue, but I don't understand the internal working of the IPB JS well enough to suggest a fix. I've tracked the issue back to the ips.ui.editor.getObj(this.scope.find('[data-role="replyComment"] [data-ipsEditor]')) call returning undefined, rather than the ckeditor object. Tracing this back, I think this is happening due to some code called from the core.front.profile.main controller - in the 'setup' method there, the browser history state is having section: 'goToProfile' ammended onto it. There is other code in the controller that watches for the history state being modified, and fires some code that unsets all IPB widgets on the page. I believe this is clearing the editor object from the .data('_editor') property on the editor element, which in turn causes the ips.ui.editor.getObj to return undefined. When the page is reloaded / visited again, because the section: 'goToProfile' value is already set on the history state for the page, then it's not set again, so no state change happens, and the code that unsets the widgets is not fired. I would assume the fix is either to not unset the widgets in the first place, or to ensure that they're set again properly afterwards. Someone on the IPB team that knows the code way better than me would have to figure out exactly what needs to happen, but hopefully this can point them in the right direction.