Thunderbird 51.0a1 (20160905030200) with built-in Lightning and fresh profile Steps to reproduce: Open the New Event / New Task dialog Actual result: Error Console shows: TypeError: completedCommand is null lightning-item-panel.js:766:5 updateMarkCompletedMenuItem chrome://lightning/content/lightning-item-panel.js:766:5 updateItemTabState chrome://lightning/content/lightning-item-panel.js:296:13 receiveMessage chrome://lightning/content/lightning-item-panel.js:122:13

I think, I found the cause: It's the call "updateConfigState(gConfig);" in [1] Since gConfig always has a property "percentComplete" set, in [2] the function "updateMarkCompletedMenuItem(aArg)" gets called. So we should make sure, that gConfig.percentComplete is only set if we are in a tab. regression from bug 1297737 [1]: https://dxr.mozilla.org/comm-central/rev/4cb52bea1cc624ae22871deaad240a6461b6b42a/calendar/lightning/content/lightning-item-iframe.js#795 [2]: https://dxr.mozilla.org/comm-central/rev/4cb52bea1cc624ae22871deaad240a6461b6b42a/calendar/lightning/content/lightning-item-panel.js#304

Comment on attachment 8805108 [details] [diff] [review] Fix V1 This changes the gConfig object, so that percentComplete is only set in case we are in a Tab.

Comment on attachment 8805108 [details] [diff] [review] Fix V1 Review of attachment 8805108 [details] [diff] [review]: ----------------------------------------------------------------- r+ with the following change: ::: calendar/lightning/content/lightning-item-iframe.js @@ +52,4 @@ > privacy: null, > status: "NONE", > showTimeAs: null, > + // percentComplete: 0 I'd prefer keeping percentComplete in the gConfig object instead of setting new members somewhere down in the code. If there is a check that depends on percentComplete being defined, then that should be changed to check for something else.

Since the call to the respective function is done by simply passing the whole object, it will execute in any case, when gConfig.percentComplete is set. This is why I chose this approach. But we can also catch the call at another place. The downside is, that this causes at least one uneeded function call.

Pushed to comm-central: -> https://hg.mozilla.org/comm-central/rev/8898cabfdac3e4744a8aeca8b82bc879f701dbde