User Agent: Mozilla/5.0 (Windows NT 5.1; rv:32.0) Gecko/20100101 Firefox/32.0 SeaMonkey/2.29.1 Build ID: 20140923221838 Steps to reproduce: upgraded seamonkey and lightning to 2.30 and 3.5b1 respectively. After that I could get no buttons to try to accept or decline a calendar invite. This is still so on SM 2.31 and LN 3.6b1. downgrading to SM 2.29.1 and LN 3.4b1 resolves the problem. Tested on Win XP SP3 and Win 7 Prof. 64bit Actual results: No accept / decline buttons Expected results: Accept / Decline bar should show up on calendar invites
OS: All → Windows 7
Hardware: All → x86_64
There has been a change with bug 782670, but this works as expected in Thunderbird. Do you just miss the buttons or the entire bar? Are there any messages in the error log? Do you have further extensions installed - if so does this occur also with those extensions disabled?
One more question: which localization do you use?
For SeaMonkey 2.31 Please try Lighting 3.6b1 build3 http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/candidates/3.6b1-candidates/build3/
I am sorry to say: No difference!
Can you please enable calendar.debug.log and calendar.debug.log.vebose in the config editor and report the appearing messages when reproducing the issue? Do other parts of Lightning e.g. the calendar views work normally?
I have done so. Then I restarted SeaMonkey - activated the error log. When starting the E-Mail client then I get a "Not defined entity Error": Zeitstempel: 10.12.2014 21:18:44 Fehler: Nicht definierte Entität Quelldatei: chrome://lightning/content/imip-bar-overlay.xul Zeile: 243, Spalte: 19 Quelltext: <menuitem id="imipMoreButton_SaveCopy" and a Warning: Zeitstempel: 10.12.2014 21:18:44 Warnung: Mutations-Ereignisse sollten nicht mehr verwendet werden. Verwenden Sie MutationObserver stattdessen. Quelldatei: chrome://calendar/content/widgets/calendar-widgets.xml Zeile: 496 When clicking on an invitation Mail (or other mail) I only get the TypeError as described in comment 3
The other parts of lightning seems to work fine. The only thing is when clicking on the lightning configuration button in the add-on manager SeaMonkey totally hangs. But this seems to be an other bug.
It might be that the localization shipped with 3.5b1 is not up-to-date or incomplete. What localization of Thunderbird do you use? What localization of Lightning do you use?
The localizations of my SeaMonkey and Lightning are german. I have tested not only with SM2.30 and LN 3.5b1 - actually I use SM2.31 and LN 3.6b3 I will try a test with the english localizations tomorrow if that helps.
The strings introduced in bug 782670 are missing in German localization until Lightning 3.6, even though they seem to have been checked in at June, 16 - they same day the patch was landed - see . Maybe there must have been something wrong with including localization to the builds?  https://l10n.mozilla.org/dashboard/history?starttime=2014-6-15&endtime=2014-6-30&tree=cal_central&locale=de
Status: UNCONFIRMED → NEW
Ever confirmed: true
Looks like another localization disaster in Lightning beta release. I searched the locales shipped with lightning-3.6b1-tb+sm-windows.xpi and the following ones are missing the new strings like lightning.imipbar.btnSaveCopy... > de, eu, id, lt, nb-NO, nn-NO, pa-IN, pt-PT, ru, sq, tr, uk, zh-TW I therefore assume those localizations are broken too. Is this sign-off problem or build problem? Don't we have some l10n test that ensures that only complete localizations will be shipped and released?
Summary: Accept / Decline Buttons disappeared in Seamonkey 2.30 and Lightning 3.5b1 → Accept / Decline Buttons disappeared in Seamonkey 2.30 and Lightning 3.5b1, due to incomplete localizations
I couldn't investigate further yet, but want to emphasize that I'm still of the opinion that the current sign-off and release process for Lightning betas is an intransparent mess. Release intervals differ from 2,5 to 7 weeks, there is no announcement before or a hint when a changeset will be tagged. And sign-offs in local-dashboards are pending for days, maybe weeks (see "tb de beta" right now). Not to talk about lags in merging l10n repositories after merge days or about breaking the builds. Localizing calendar in 2014 sometimes felt like a gambling game. That said, I'll have to take the blame for the broken German localization, though. And please excuse my harsh words, it's just frustrating to have broken betas again.
I don't think it's about blaming anybody here. We should think about how to deal with the current beta - comment #12 indicates this spreads wider than to just a single localization and will make email invitation unusable for 13 localizations in total. Maybe Philipp can make a statement whether he will build another beta for 3.6 esp. for the Seamonkey users once the missing strings have been backported. In general, the situation may get better in terms of a more reliable timing, once we start shipping Lightning with Thunderbird, which is planned for TB38. Nevertheless, it seems to be mainly a lack of communication based on Robert's description.
I agree the current localization system is a mess, I'm sorry about that. The problem is in part that Mark is no longer doing l10n sign-offs for Thunderbird, I am not sure if we have someone else doing this now. Then we have the problem that Lightning has its own shipped-locales file and I haven't been checking if this is in sync with the locales that are green on each beta. I don't know how feasible it would be to trigger another 3.6 beta, because to do this we'd have to do another Thunderbird beta build and make sure the sign-offs are taken care of there. Might be worth opening a topic on m.d.l10n and CC'ing a few Thunderbird folks. I don't know a good solution for this in the future. Ideally, if we could get all current Thudnerbird localizers to also handle the Lightning strings, we could just use Thunderbird's shipped-locales list directly and make the Thunderbird dashboard fail if Lightning strings are missing. The other thing we could try is to set up the l10n merge script, although last time I looked into this it was a lot of trouble since its usually done in a separate build step and we'd have to do it during the repack step.
Marc, does the problem still exists using SeaMonkey 2.33 with Lightning 3.8b2?
Hi Stefan - no that looks not good - I am not even able to see the invitation with that version. When I revert back to 2.32 and the us version 3.7b1 everything works fine.
Hm, works for me using german SeaMonkey 2.33 and Lightning 3.8b2 with used or clean profile. The invitation from another Lightning installation was shown and I could use the imip bar to add the event to my calendar. The error message from comment #7 (missing entity for imipMoreButton_SaveCopy) is not shown anymore, and that doesn't surprise me because the strings from bug 782670 are definitely part of the 3.8b2 package. So I'd expect that the underlying problem now differs form the original one.
Marc, what other email or calendar related extensions do you use? Can you plesse also check in the config editor that you have calendar.icaljs disabled?
Marc, have you updated to Seamonkey 2.33 and Lightning 3.8b2? This should be fixed by now.
Hi Philipp - yes sure - this was the test stefan ask me to do.
Ah yes, sorry I missed that. The German locale was updated between the two betas, so I thought it may be that. I think the consensus we reached on another bug was to not update the German locale any further on 3.8. In the meanwhile, could you update to Seamonkey 2.34 beta and Lightning 3.9b1 to see if this fixes it? Alternatives are to downgrade to Seamonkey 2.32 until 2.34 is released, or switch to the en-US locale for Seamonkey 2.33.
Resolving as WFM because the localizations were updated. There is a new and different issue (TypeError: Components.classes[cid] is undefined) with Seamonkey 2.33 and Lightning 3.8b2 but it is already tracked with Bug 1144285.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.