Last modified: 2014-03-07 00:20:34 UTC
When VisualEditor deactivates itself after Parsoid fails, this exceptions thrown because the property never got set. ve.init.mw.ViewPageTarget.prototype.deactivate = function(override) { if (..) { if (..) { this.deactivating = true; if (ve.msg('accesskey-save') !== '-' && ve.msg('accesskey-save') !== '') { this.elementsThatHadOurAccessKey.attr('accesskey', ..); ^ ve.init.mw.ViewPageTarget.prototype.setupToolbarButtons = function () { .. if (ve.msg('accesskey-save') !== '-' && ve.msg('accesskey-save') !== '') { this.elementsThatHadOurAccessKey = $( .. ); The code in deactivate() shouldn't be repeating conditions like that as they're no longer semantically relevant, and in this case even incorrect. Instead the top one (which usually runs after setupToolbarButtons) should limit its interest to elementsThatHadOurAccessKey itself which we either set to null or to a jQuery object.
Change 117224 had a related patch set uploaded by Krinkle: mw.ViewPageTarget: Check elementsThatHadOurAccessKey before accessing https://gerrit.wikimedia.org/r/117224
Change 117224 merged by jenkins-bot: mw.ViewPageTarget: Check elementsThatHadOurAccessKey before accessing https://gerrit.wikimedia.org/r/117224
Change 117228 had a related patch set uploaded by Alex Monk: mw.ViewPageTarget: Check elementsThatHadOurAccessKey before accessing https://gerrit.wikimedia.org/r/117228
Change 117230 had a related patch set uploaded by Jforrester: mw.ViewPageTarget: Check elementsThatHadOurAccessKey before accessing https://gerrit.wikimedia.org/r/117230
Change 117230 merged by jenkins-bot: mw.ViewPageTarget: Check elementsThatHadOurAccessKey before accessing https://gerrit.wikimedia.org/r/117230
Change 117228 merged by jenkins-bot: mw.ViewPageTarget: Check elementsThatHadOurAccessKey before accessing https://gerrit.wikimedia.org/r/117228