1921611 - cannot dismiss reminder - Server Replied with 400 - Unexpected status modifying item to Gmail: 400

Status: RESOLVED FIXED

(Calendar :: Alarms, defect)

Description

[raal]

Attachment: log.txt

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.6478.114/115 Safari/537.36

Steps to reproduce:

TB 132.0a1 (2024-09-27) (64-bit). It started one or two days ago, I had no such problems before.

Actual results:

I have calendar item in gmail calendar. When reminder appear, I press button Dismiss and nothing happen. Reminder item is still in reminder window.

Expected results:

Item should disappear.
Error log:
NS_ERROR_FAILURE: Server Replied with 400 CalCachedCalendar.sys.mjs:770
Calendar: CalDAV: Unexpected status modifying item to Gmail: 400

Comment 1

[Wayne Mery (:wsmwk)]

Using daily from Oct 24 or 23, similar issue here
Calendar: CalDAV: Unexpected status modifying item to Wayne Mery: 400 BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN V

Other dismiss issues https://mzl.la/3YDuyfD

Comment 3

[Brian]

Attachment: Screenshot 2026-01-24 at 17.15.31.png

I am new to TB and experiencing the same problem. It would appear that there is no actual payload sent with the PUT request, which seems odd.

Comment 4

[Brian]

I set up a proxy to do a little investigating and found out the following:

The request is indeed sending with a payload. I’m not sure why the dev console says otherwise.

In my testing, I could only reproduce this with Google Calendar events that were auto-created. Presumably Google rejects certain modifications to the event because of this. For instance, I cannot modify the name or description of such events even in the Google Calendar web app.

Because of this, the X-MOZ-* properties are causing the PUT request to fail. When updating the event on dismissal, TB is adding 3 properties:

X-MOZ-GENERATION
X-MOZ-GOOGLE-HTML-DESCRIPTION
X-MOZ-LASTACK

I do not know the significance of X-MOZ-GENERATION, but it seems the maintainers themselves have some doubts about its utility. X-MOZ-GOOGLE-HTML-DESCRIPTION appears to be for informational purposes only and I don’t see it actually used anywhere. I assume X-MOZ-LASTACK is used by TB to know robustly whether it’s appropriate to display the alert dialog or not on startup, but it also looks like there is some best-effort handling of snooze/dismissal for read-only calendars.

I tried to remove X-MOZ-GOOGLE-HTML-DESCRIPTION and X-MOZ-GENERATION from the payload and move X-MOZ-LASTACK inside the VALARM, and the PUT request actually succeeds. Unfortunately, Google doesn’t seem to actually store it, as it is not returned with subsequent fetches of the event. So I don’t see an obvious way to persist ack time with such events and they should handled here as if they were read-only.

Regardless, it would appear that the real root cause is that TB seems to believe these items can be modified, when really they can’t. I’m not sure if that’s something Mozilla can fix or Google needs to fix. Regardless, it would seem this problem is easily solved with a try/catch block here so that we continue as if the item were in fact read-only in the event of an unexpected status code from the server.

I’ve already tested this locally and it works well. I will try to submit a patch, but I am not at all familiar with mercurial so wish me luck.

Comment 5

[Brian]

Well I suppose I need a voucher in order to submit a patch.

@mkmelin Is this something you could help me with? I’ve created a request for Level 1 access here

Comment 6

[Magnus Melin [:mkmelin]]

See https://developer.thunderbird.net/thunderbird-development/fixing-a-bug#submitting-a-patch
You don't actually need privileges to submit a patch through Phabricator. Please submit a patch first, and then I can vouch for L1 access.

Comment 7

[Brian]

Attachment: Bug 1921611: Handle snooze/dismiss errors r?mkmelin

Comment 8

[Brian]

Sorry, I shouldn’t have skipped directly to ‘Landing a Patch’ when I first looked at the docs. Thank you for your patience in pointing me in the right direction. Patch submitted!

Comment 9

[Magnus Melin [:mkmelin]]

Brian, is this about bug 1971160?

Comment 10

[Brian]

I did not experience this specifically with Birthday notifications, but comment #18 leads me to believe it is indeed the same root cause.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/9bb559a9fe85
Handle snooze/dismiss errors r=mkmelin

Comment 12

[Magnus Melin [:mkmelin]]

Comment on attachment 9540619 [details]
Bug 1921611: Handle snooze/dismiss errors r?mkmelin

Uplift Approval Request

• Please state case for uplift consideration and ensure bug severity is set: Fixing a common annoyance
• User impact if declined: Alarms keep popping up even if you dismissed them
• Is this code covered by automated tests?: No
• Has the fix been verified in Daily?: Yes
• Has the fix been verified in Beta?: No
• Needs manual test from QA?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Very confined change
• Does the fix cause any migrations to be skipped?: No
• String changes made/needed: none

Comment 13

[Corey Bryant]

Comment on attachment 9540619 [details]
Bug 1921611: Handle snooze/dismiss errors r?mkmelin

[Triage Comment]
I'm not sure this meets uplift criteria. Can you justify uplift reasoning based on criteria at https://developer.thunderbird.net/releases/uplifting-fixes ?

Comment 15

[Wayne Mery (:wsmwk)]

Perhaps one of

• Fixes for high-impact regressions with a broad impact.
• Fixes for high-impact bugs in a major feature.

Magnus, Does this just fix a small segment of reminder flaws? Or does it fix one or more of https://mzl.la/4qZZBgy which are driving people crazy with reminders popping up and interrupting their work? (including me, the point where I have disabled most of my calendars)

Comment 16

[Magnus Melin [:mkmelin]]

There are a lot of issues around dismissing events and tasks. This fixes a large part of them, though perhaps not all - it's hard to say how much as I don't think we have the root causes figured out.