Aldaviva / VivaldiCustomLauncher

🎻 Intercept executions of Vivaldi to add custom arguments and apply tweaks files
Apache License 2.0
6 stars 1 forks source link

Unfuck M3 #3

Closed Aldaviva closed 2 years ago

Aldaviva commented 2 years ago

It's a beta but maybe I can fix some of its more annoying behaviors.

Aldaviva commented 2 years ago
Aldaviva commented 2 years ago

As of Vivaldi 5.4, deleting an email message seems to successfully make it disappear from K-9 mail as well, so I'm marking that as complete. I haven't had many connection issues in a long time, too.

All-day calendar events are still a reproducible issue though, I probably need to figure out how to intercept and log CalDAV traffic, possibly with debugging packed apps and network inspector, or Fiddler, or enabling some sort of extended logging in MDaemon if possible.

Aldaviva commented 2 years ago

iCalendar date-time snippets from different actors to figure out where the off-by-1-day problem is.

The following example is for an all-day event on 2022-10-19.

Note that Vivaldi 5.5 appears to contain a regression from 5.4 where creating a new calendar event no longer offers an All Day checkbox. I assume this will be fixed in a future update.

A: Event created in MDaemon webmail, returned over CalDAV to Vivaldi

DTSTART;VALUE=DATE:20221019
DTEND;VALUE=DATE:20221020

This appears correctly on 2022-10-19 on both MDaemon webmail and Vivaldi.

B: Event A modified by Vivaldi to add description, leaving date unchanged

DTEND;VALUE=DATE:20221019
DTSTART;VALUE=DATE:20221018

This appears incorrectly on 2022-10-18 in webmail (one day too early), but correctly on 2022-10-19 in Vivaldi.

The above ICS snippet came from Vivaldi's PUT request to MDaemon, showing that Vivaldi sent the wrong date when it was modifying the event, even though the date should not have changed from the values shown in A. This confirms that the defect is in Vivaldi, not MDaemon. The next request is Vivaldi immediately issuing a GET request for the same event, where MDaemon dutifully returns the new (wrong) date given by Vivaldi.

Complete request showing incorrect date set by Vivaldi

PUT https://aldaviva.com:444/webdav/caldav/aldaviva.com/ben/b64=Q2FsZW5kYXI/fb3a5bbf197e4c9e99b77bdd1f97b88c.ics HTTP/1.1
Host: aldaviva.com:444
Connection: keep-alive
Content-Length: 362
Cache-Control: max-age=0
sec-ch-ua: "Chromium";v="106", "Not;A=Brand";v="99"
Content-Type: text/calendar; charset=utf-8
If-Match: "2022-10-06T03:53:11.000Z"
sec-ch-ua-mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36
sec-ch-ua-platform: "Windows"
Accept: */*
Sec-Fetch-Site: none
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9

BEGIN:VCALENDAR
PRODID:-Vivaldi Calendar V1.0//EN
VERSION:2.0
CALSCALE:GREGORIAN
DTSTAMP:20221006T080202Z
BEGIN:VEVENT
DTSTAMP;VALUE=DATE-TIME:20221006T080202Z
DESCRIPTION:Adding description!
DTEND;VALUE=DATE:20221019
DTSTART;VALUE=DATE:20221018
SEQUENCE:1
SUMMARY:CalDAV All-Day Test 1
UID:fb3a5bbf197e4c9e99b77bdd1f97b88c
END:VEVENT
END:VCALENDAR
Aldaviva commented 2 years ago

The date off-by-one error seems to be caused by a UTC conversion that affects both rendering and saving, and it only occurs when the user's time zone has a negative UTC offset (such as -0700 in America/Los_Angeles). You can change your OS clock to UTC and the issue does not recur with the above steps.

Disabling the UTC conversion for all-day events also fixes the saving defect, but introduces a rendering defect where the event appears to end one day later than intended.

Aldaviva commented 2 years ago

The date off-by-one error was caused by Vivaldi using date offsets (numeric milliseconds since Unix epoch) as timeless local dates, but being inconsistent about the time zone that should be used when formatting them. The start and end dates for all-day events were midnight UTC, but the serializer that generates the iCalendar data to PUT to the CalDAV server formats them using the local time zone instead of UTC. When the local zone has a negative UTC offset, this causes the day of the month to be 1 day small than expected. For example, 2022-10-19T00:00:00Z was being formatted in my local America/Los_Angeles time zone, which corresponds to 2022-10-18T17:00:00-0700, or 20221018 when formatted as YYYYMMDD for the iCalendar DTSTART and DTEND fields.

To fix this, I am adding a tweak to VivaldiCustomLauncher that modifies the iCalendar serializer for all-day events to format the dates (Moment objects) in UTC instead of the local time zone (e.g. moment(millis).utc().format("YYYYMMDD")).

With this tweak in place, you can modify the description of an existing event in Vivaldi, and the ICS PUT will contain the expected date values:

DTEND;VALUE=DATE:20221020
DTSTART;VALUE=DATE:20221019

The event will not move to the wrong day in other CalDAV clients like MDaemon webmail and OpenSync for Android, and it will also appear correctly in Vivaldi with the intended start date and duration (it will not span 2 days like my previous attempt to fix this).

Aldaviva commented 2 years ago

Released fix for all-day events in VivaldiCustomLauncher 1.2.4.

With this, all of the known issues have been resolved by either me or Vivaldi. M3 is working well for me now, so I'm going to close this issue.