734966 - "snooze all" doesn't work [Mac]

Status: RESOLVED FIXED

(Calendar :: Alarms, defect)

Description

[Hal Wine [:hwine] use NI!]

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.

Comment 1

[Matthew Mecca [:mmecca]]

It seems to be working for me - can you explain what exactly is happening when you try to Snooze All?

Comment 2

[Hal Wine [:hwine] use NI!]

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.

Comment 3

[Matthew Mecca [:mmecca]]

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?

Comment 4

[Hal Wine [:hwine] use NI!]

Attachment: 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.

Comment 5

[Matthew Mecca [:mmecca]]

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".

Comment 6

[Hal Wine [:hwine] use NI!]

Attachment: console output as requested

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?

Comment 7

[Hal Wine [:hwine] use NI!]

(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)

Comment 8

[Matthew Mecca [:mmecca]]

(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.

Comment 9

[Hal Wine [:hwine] use NI!]

Attachment: output from snooze-all from 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)

Comment 10

[Matthew Mecca [:mmecca]]

The next thing I would try is to test on a clean profile with a local calendar.

Comment 11

[Hal Wine [:hwine] use NI!]

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.

Comment 12

[Matthew Mecca [:mmecca]]

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.

Comment 13

[Hal Wine [:hwine] use NI!]

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)

Comment 14

[David von Oheimb]

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.

Comment 15

[François]

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.

Comment 16

[briansynch2010]

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

Comment 17

[[e-mail]]

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.

Comment 18

[jsantossilva]

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.

Comment 19

[Wayne Mery (:wsmwk)]

Easy to fix?

Comment 20

[jsantossilva]

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.

Comment 21

[Geoff Lankow (:darktrojan)]

(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.

Comment 22

[Wayne Mery (:wsmwk)]

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

Comment 23

[[e-mail]]

> 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...

Comment 24

[Richard Marti (:Paenglab)]

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.

Comment 25

[Richard Marti (:Paenglab)]

TB 60 shows no error.

Comment 26

[jsantossilva]

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.

Comment 27

[jsantossilva]

Was just able to test. Still doesn't work.

Comment 28

[Geoff Lankow (:darktrojan)]

(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.

Comment 29

[Geoff Lankow (:darktrojan)]

Attachment: 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?

Comment 30

[[e-mail]]

(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.

Comment 31

[Geoff Lankow (:darktrojan)]

Attachment: 734966-snooze-2.diff

I forgot to make the same change for Windows that I did for Linux.

Comment 32

[Geoff Lankow (:darktrojan)]

(In reply to [e-mail] 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

Comment 33

[[e-mail]]

(In reply to Geoff Lankow (:darktrojan) from comment #32)
> (In reply to [e-mail] 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.

Comment 34

[Geoff Lankow (:darktrojan)]

(In reply to [e-mail] 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.

Comment 35

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/9bc477f5f7d3
Fix "snooze all" button on Mac; r=Fallen

Comment 36

[Geoff Lankow (:darktrojan)]

Comment on attachment 9033678 [details] [diff] [review]
734966-snooze-2.diff

I should've asked for this approval earlier.

Comment 37

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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 :)

Comment 38

[Geoff Lankow (:darktrojan)]

It was reported 7 years ago, so I'm guessing it affects ESR.

Comment 39

[Jorg K (CEST = GMT+2)]

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.

Comment 40

[Jorg K (CEST = GMT+2)]

TB 65 beta 2, Cal 6.7:
https://hg.mozilla.org/releases/comm-beta/rev/8e53a70093a9727303bed0bba44eb795a981cc54

Comment 41

[Geoff Lankow (:darktrojan)]

Attachment: 734966-snooze-esr-2.diff

The two chunks that don't apply are totally unnecessary, but since I created this patch without them, you might as well have it.

Comment 42

[Jorg K (CEST = GMT+2)]

Comment on attachment 9033824 [details] [diff] [review]
734966-snooze-esr-2.diff

Carrying over previous approval.

Comment 43

[Jorg K (CEST = GMT+2)]

TB 60.5 ESR / Cal 6.2.5:
https://hg.mozilla.org/releases/comm-esr60/rev/c37cbbf8c010cbe94c711693a245ce4491747726

Comment 44

[Jorg K (CEST = GMT+2)]

Attachment: snooze-popup.png

Looks like you broke the snooze on Windows :-(

Comment 45

[Richard Marti (:Paenglab)]

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

Comment 46

[Jorg K (CEST = GMT+2)]

Attachment: 734966-ESR60-follow-up.patch

Comment 47

[Jorg K (CEST = GMT+2)]

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?

Comment 48

[Richard Marti (:Paenglab)]

Attachment: screenshot.png

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

Comment 49

[Geoff Lankow (:darktrojan)]

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

Comment 50

[Jorg K (CEST = GMT+2)]

Attachment: popup.png

:-(

Comment 51

[Richard Marti (:Paenglab)]

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

Comment 52

[Jorg K (CEST = GMT+2)]

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 :-(

Comment 53

[Jorg K (CEST = GMT+2)]

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?

Comment 54

[Jorg K (CEST = GMT+2)]

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

Comment 55

[Jorg K (CEST = GMT+2)]

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

Comment 56

[Geoff Lankow (:darktrojan)]

Attachment: 734966-snooze-binding-esr.diff

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.

Comment 57

[Geoff Lankow (:darktrojan)]

https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=286c0fff2c7dae48ac72c2047f9a5515850d26cc

Comment 58

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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?

Comment 59

[Jorg K (CEST = GMT+2)]

This works now on ESR 60, thanks.

Comment 60

[Jorg K (CEST = GMT+2)]

TB 60.5 ESR / Cal 6.2.5:
https://hg.mozilla.org/releases/comm-esr60/rev/0bcd3b0d9039cc5b9856d2f57295623706900461
https://hg.mozilla.org/releases/comm-esr60/rev/a0feb7ec4fd6981f5297e500fc6499e03680dbbd