Closed Bug 734966 Opened 8 years ago Closed 11 months ago

"snooze all" doesn't work [Mac]

Categories

(Calendar :: Alarms, defect)

Lightning 1.2
x86
macOS
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: hwine, Assigned: darktrojan)

References

Details

Attachments

(10 files, 1 obsolete file)

When a reminder pops up, there is that oh-so-tempting button on the dialog border labeled "Snooze all...", but it does not work.

Selecting each reminder individually and using the snooze button there does work.
It seems to be working for me - can you explain what exactly is happening when you try to Snooze All?
Nothing is happening. 

Button visually responds normally to click (highlights, presents snooze time menu, each item highlights properly). On mouse up with any snooze interval chosen, nothing further happens visually.

I just tried disabling "muttator" extension - still same behavior - it is 100% reproducible, so if there is any debugging/logging I can do, just point me to how to do it.
Are there any calendar related error messages in Tools > Error Console?

Does the number of alarms, source calendar, or repeat setting of the items make any difference?
Attached file error log during event
Error log showing:
 - creation of event
 - display of reminder
 - 2 attempts to "snooze all" (no text from that time)
 - 1 successful attempt to snooze just that event

There is only one event in the reminder display, from one calendar (zimbra). 

Let me know what debug steps you want next.
As a test I tried copying the event from your log and pasting it into a CalDAV calendar (not zimbra, but I don't think that should make a difference here), the Snooze All worked fine for me. I don't have a mac to test with, maybe this is problem is platform specific.

Maybe you can try this and see what happens: When a reminder pops up and the reminder dialog is still open, got to Tools -> Error Console. In the "Code:" box, paste the following (as a single long line of code):


Components.classes["@mozilla.org/appshell/window-mediator;1"].getService(Components.interfaces.nsIWindowMediator).getMostRecentWindow("Calendar:AlarmWindow").snoozeAllItems(1);


then click "Evaluate".
Per prior comment, executed JS statement, twice after clearing all existing log messages.

First run: one error cell - reminder window was not frontmost

Second run: rest of log output - reminder window was frontmost

question: "dismiss all" works - is there any JS of interest to show the list it is working with?
(In reply to Matthew Mecca [:mmecca] from comment #5)
> Maybe you can try this and see what happens: 

No change in behavior - event still stays visible (I forgot to note this in comment #6)
(In reply to Hal Wine [:hwine] from comment #7)
> No change in behavior - event still stays visible (I forgot to note this in
> comment #6)

Sorry, I should have been more clear that the expected result would only have been a one minute snooze. Is there any chance the reminder dialog closed for a short time and popped back up in the background? Maybe we could try a slightly longer snooze by using the same steps in comment #5 but substituting the parameter of last part to "snoozeAllItems(5);"?

It appears from the log that the item was in fact modified this time, unlike when you tried to Snooze All in comment #4. That could indicate that the snoozeAllItems function is working properly, but the DOM isn't calling into it properly, but if that's the case I would still expect the dialog to clear and close when we call the function from the error console.
Okay - the snooze all worked as expected from evaluating the JS expression:
 - the item disappeared from the dialog
 - the dialog disappeared
 - it represented 5 minutes later (the value I set things to)

So, it appears that the code is working, but something has become unhooked on the GUI side. (At least in my instance)
The next thing I would try is to test on a clean profile with a local calendar.
I'm not familiar with that process with TB - is there a page describing the steps? Bottom line - I can't risk my current profile.
You can find documentation on that here:
http://kb.mozillazine.org/Profile_manager

I would suggest as follows:
1) Follow the instructions on that page to create a new profile. Make sure to uncheck the "Don't ask at startup" option for now.
2) Start TB with the new profile. Cancel out of the mail new account wizard, since we're using this profile to primarily test Lightning.
3) Go to File -> New -> Other Accounts..., select "Blogs and News Feeds", and next through the wizard. This will prevent TB from showing the new account wizard at each startup.
4) Install Lightning. Don't install any other extensions at this point. Restart TB.
5) Go to the TB preferences dialog (I'm not sure if it's Edit -> Preferences or Tools -> Preferences on mac). Go to Advanced, General tab. Click "Config Editor...". Find the preferences calendar.debug.log and calendar.debug.log.verbose, set those to true. Restart TB.

Now you should be ready to start the additional testing. I would try the following:
1) First I would try creating a new event in the default storage calendar "Home" with a reminder, then try to Snooze All when it fires. If that works..
2) Add your zimbra calendar, repeat the test (based on your logs I don't think this will make any difference, but it won't hurt to test that). If that works...
3) Start adding in any other extensions you have installed in your main profile, repeating the test to see if there may be a conflict.
Finally found some time - thanks for the details (I've gotten spoiled with the app for FF & forgotten about -profilemanager).

With TB 10.0.2 & Lightning 1.2.3, step (1) exhibits the problem (snooze all doesn't work on event in "home" calendar).

In getting to this point, I uncovered a "can't update to 11.0" issue in TB. Once I straighten that out with the TB team, I'll see if I can still repo (likely in TB 11, 1.3 Lightning)
I can confirm that Snooze All has no effect, with Lightning 1.4 on Mac OS 10.7.3.
It does not even give any error message, e.g., on the Java console. 
Individual Snooze does work.
Same problem here, for a couple of years, I would say. Currently running Lightning 2.6.4, TB 24.3.0, OS X 10.9.2.
I've also had the same problem, only on mac (fine w/ Linux and Windows) for years. TB 38.4.0, Lightning 4.0.4, OS 10.10.5
Vow, this seems very old issue. It is still present on my system: Thunderbird 52.5.2 with Ligthning 5.4.5.2 On MacOSX 10.9.5.
Snooze All does not have any effect, so I have to snooze each event manually. Very annoying.
If it's worth something after 7 years (is that so long?), I also feel the same problem with macos High Sierra, TB 52.9.1 and Lightning 5.4.

Second "Very annoying".

Anyway, this does not prevent me of finding TB the best email client for me.
Easy to fix?
Flags: needinfo?(geoff)
See Also: → 752179
Summary: "snooze all" doesn't work → "snooze all" doesn't work [Mac]
Forgot to add something that I deem relevant: My MacBook Pro dual-boots macOS and gentoo-linux and this only happens on macOS, now Mojave 10.14.2.
It performs correctly if I boot Gentoo with same version of TB, now 60.3.3 with Lightning 6.2.3.3.
Profile is the same on both OS's as is the calendar backend, which is a NextCloud server.
(In reply to Wayne Mery (:wsmwk) from comment #19)
> Easy to fix?

I haven't got a Mac, so no, although I did find something I think *might* cause this problem. If somebody wants to try it out, I created a build which can be found here (target.dmg):

https://tools.taskcluster.net/groups/PTPTb4bVTP6OKs8C2AegeA/tasks/DHPPmzuiRseeRsozuiGk2g/runs/0/artifacts

Just bear in mind that you shouldn't use your normal profile as this build is based on Thunderbird 66, not 60.
Flags: needinfo?(geoff)
jsantos, andriusr,

please try https://queue.taskcluster.net/v1/task/DHPPmzuiRseeRsozuiGk2g/runs/0/artifacts/public/build/target.dmg 

dont use your normal profile - see https://support.mozilla.org/en-US/kb/using-multiple-profiles
Flags: needinfo?(jsantossilva)
Flags: needinfo?(andriusr)
> please try
> https://queue.taskcluster.net/v1/task/DHPPmzuiRseeRsozuiGk2g/runs/0/
> artifacts/public/build/target.dmg 

Hi Wayne,
I have tried test build, however, behavior is exactly the same - Snooze All does not have any effect.
I did some little investigation in xpi file last night. In my opinion, the problem is that onsnooze event (as described in line 41 of calendar-alarm-dialog.xul) is not fired, and snoozeAllItems(aDurationMinutes) is not executed at all. 
There is complicated net of callbacks and events for pop-up menu that is hard to follow, and I think something here prevents onsnooze event fired. Workaround would be not to re-use menu for individual reminders and create dedicated menu just for Snooze All button with simplified event/callback logic, I guess. 
One more observation: snoozeAllItems() seems to be perfectly executed when I am closing alarm window with Esc key or red window closing button (on the left top corner of window). In this case finishWindow() I guess is excuted, and it adds default snooze to all reminders using snoozeAllItems(). This is possible workaround for this issue- in Preferences on should configure default snooze value, and then close alrm window with Esc - default snooze is added to all reminders...
Flags: needinfo?(andriusr)
Yes, tested the try build too and it doesn't snoozewith "Snooze All". When using it I get this error:

 TypeError: document.getBindingParent(...) is null[Learn More] calendar-alarm-widget.xml:298:27

 snoozeAlarm chrome://calendar/content/widgets/calendar-alarm-widget.xml:298
 snoozeItem chrome://calendar/content/widgets/calendar-alarm-widget.xml:314
 oncommand chrome://calendar/content/calendar-alarm-dialog.xul:1 

Testing now TB 60.4 to check if the error is the same.
TB 60 shows no error.
wsmwk
I'm having trouble testing it.

I copied my actual profile to *.save, created new profile using the copy I made, launched TB Daily downloaded from your link pointed to the test profile just copied.

Then, on the Addons Manager, I saw that all extensions except one are incompatible, including Lightning 6.2.3.3.
Clicked "check for update" with no success. Clicked the Lightning Homepage Link but it showhs me an older 5.4 version.

So, I don't have a calendar to test, please give me a lead.
Flags: needinfo?(jsantossilva)
Was just able to test. Still doesn't work.
(In reply to Richard Marti (:Paenglab) from comment #24)
> Yes, tested the try build too and it doesn't snoozewith "Snooze All". When
> using it I get this error:
> 
>  TypeError: document.getBindingParent(...) is null[Learn More]
> calendar-alarm-widget.xml:298:27
> 
>  snoozeAlarm chrome://calendar/content/widgets/calendar-alarm-widget.xml:298
>  snoozeItem chrome://calendar/content/widgets/calendar-alarm-widget.xml:314
>  oncommand chrome://calendar/content/calendar-alarm-dialog.xul:1 
> 
> Testing now TB 60.4 to check if the error is the same.

(In reply to Richard Marti (:Paenglab) from comment #25)
> TB 60 shows no error.

That wasn't the answer I wanted but it was surprisingly helpful. I now know why this code behaves differently on Mac.
Attached patch 734966-snooze-1.diff (obsolete) — Splinter Review
The test I'm adding here only lightly tests the snooze all and dismiss all buttons, not the buttons for individual reminders, but it's better than nothing, right?
Assignee: nobody → geoff
Status: NEW → ASSIGNED
Attachment #9033471 - Flags: review?(philipp)
(In reply to Geoff Lankow (:darktrojan) [probably offline right now] from comment #29)
> Created attachment 9033471 [details] [diff] [review]
> 734966-snooze-1.diff
> 
> The test I'm adding here only lightly tests the snooze all and dismiss all
> buttons, not the buttons for individual reminders, but it's better than
> nothing, right?

Is there any way to test it? I have noticed, that .xpi files that are in extensions folder on MacOSX could not be opened by zip archiver anymore.
I forgot to make the same change for Windows that I did for Linux.
Attachment #9033471 - Attachment is obsolete: true
Attachment #9033471 - Flags: review?(philipp)
Attachment #9033678 - Flags: review?(philipp)
(In reply to andriusr@yahoo.com from comment #30)
> Is there any way to test it?

Yes, here's a build from a test run. I've been told already that it works (and it passes the new test I wrote).

https://queue.taskcluster.net/v1/task/bhiL8MAwQKeG0fSo1YSWtA/runs/0/artifacts/public/build/target.dmg
(In reply to Geoff Lankow (:darktrojan) from comment #32)
> (In reply to andriusr@yahoo.com from comment #30)
> > Is there any way to test it?
> 
> Yes, here's a build from a test run. I've been told already that it works
> (and it passes the new test I wrote).
> 
> https://queue.taskcluster.net/v1/task/bhiL8MAwQKeG0fSo1YSWtA/runs/0/
> artifacts/public/build/target.dmg

Indeed, it works on my MacOSX.
You probably should remove comment:
// The onsnooze attribute is set on the menupopup, this binding is
// instanciated on the menupopup's arrowscrollbox. Therefore we need
// to go up one node.
It does not make sense anymore.
Attachment #9033678 - Flags: review?(philipp) → review+
(In reply to andriusr@yahoo.com from comment #33)
> You probably should remove comment:
> // The onsnooze attribute is set on the menupopup, this binding is
> // instanciated on the menupopup's arrowscrollbox. Therefore we need
> // to go up one node.
> It does not make sense anymore.

You're right, I intended to but clearly never did.
Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/9bc477f5f7d3
Fix "snooze all" button on Mac; r=Fallen
Status: ASSIGNED → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → 6.8
Comment on attachment 9033678 [details] [diff] [review]
734966-snooze-2.diff

I should've asked for this approval earlier.
Attachment #9033678 - Flags: approval-calendar-esr?(philipp)
Attachment #9033678 - Flags: approval-calendar-beta?(philipp)
Comment on attachment 9033678 [details] [diff] [review]
734966-snooze-2.diff

Is this bug really an issue on ESR? If so I am fine with backporting, I'm just surprised :)
Attachment #9033678 - Flags: approval-calendar-esr?(philipp)
Attachment #9033678 - Flags: approval-calendar-esr+
Attachment #9033678 - Flags: approval-calendar-beta?(philipp)
Attachment #9033678 - Flags: approval-calendar-beta+
It was reported 7 years ago, so I'm guessing it affects ESR.
Comment on attachment 9033678 [details] [diff] [review]
734966-snooze-2.diff

Sorry, this doesn't apply. I've only looked at testEventDialog.js and that's 100% different.
Flags: needinfo?(geoff)
Attachment #9033678 - Flags: approval-calendar-esr+
The two chunks that don't apply are totally unnecessary, but since I created this patch without them, you might as well have it.
Flags: needinfo?(geoff)
Attachment #9033824 - Flags: approval-calendar-esr?(philipp)
Comment on attachment 9033824 [details] [diff] [review]
734966-snooze-esr-2.diff

Carrying over previous approval.
Attachment #9033824 - Flags: approval-calendar-esr?(philipp) → approval-calendar-esr+
TB 60.5 ESR / Cal 6.2.5:
https://hg.mozilla.org/releases/comm-esr60/rev/c37cbbf8c010cbe94c711693a245ce4491747726
Target Milestone: 6.7 → 6.2.5
Attached image snooze-popup.png

Looks like you broke the snooze on Windows :-(

Flags: needinfo?(geoff)

Adding <?xml-stylesheet href="chrome://global/skin/popup.css" type="text/css"?> to calendar-alarm-dialog.xul would help.

Flags: needinfo?(geoff)
Attachment #9036692 - Flags: review?(geoff)
Attachment #9036692 - Flags: review?(geoff) → review+

Thanks for the review, but it doesn't work, see build here:
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=d0f71e24454ad6b2110fdea663acd6ccebc7cabc

Looks like the snooze pulldown/popup has a hover background, but the overall box doesn't. Would you like to see a screenshot?

Flags: needinfo?(richard.marti)
Flags: needinfo?(geoff)
Attached image screenshot.png

Yes, please. This is how this build looks here.

Flags: needinfo?(richard.marti)

It worked fine on my Win10 VM too. According to the CSS it should always have a background.

Flags: needinfo?(geoff)
Attached image popup.png

:-(

Is the correct Lightning used or is it an older one?

Well, Lightning is a pain when it comes to this. I used a TB 60.5 before, that's how I found it. So now I followed all the usual steps to get to the newer version. I can reinstall and remove the thing from the profile to be sure :-(

OK, after the super-hard reset it works now, however, clicking the [X] gives
TypeError: this.hidePopup is not a function - calendar-alarm-widget.xml:340:13 :-(

New bug?

Working OK on TB 65 beta though, didn't try trunk.

Geoff, can we get this fixed a.s.a.p. or I'll have to back the whole thing out from the ESR. Looks like it got damaged here:
https://hg.mozilla.org/releases/comm-esr60/rev/c37cbbf8c010cbe94c711693a245ce4491747726#l2.31

Flags: needinfo?(geoff)

Moving the binding onto the menupopup itself lost the original binding. I'm not quite sure how it works anyway on beta and trunk, but it's probably something to do with the XBL changes.

Flags: needinfo?(geoff)
Attachment #9037462 - Flags: review?(philipp)
Attachment #9037462 - Flags: approval-calendar-esr?(philipp)
Attachment #9036692 - Flags: approval-calendar-esr?(philipp)
Comment on attachment 9037462 [details] [diff] [review]
734966-snooze-binding-esr.diff

Review of attachment 9037462 [details] [diff] [review]:
-----------------------------------------------------------------

Can you test this on beta/trunk? The code looks ok, but it would be good to avoid any regressions due to this. Or is this patch only for ESR?
Attachment #9037462 - Flags: review?(philipp)
Attachment #9037462 - Flags: review+
Attachment #9037462 - Flags: approval-calendar-esr?(philipp)
Attachment #9037462 - Flags: approval-calendar-esr+
Attachment #9036692 - Flags: approval-calendar-esr?(philipp) → approval-calendar-esr+

This works now on ESR 60, thanks.

You need to log in before you can comment on or make changes to this bug.