Closed Bug 1685918 Opened 4 years ago Closed 4 years ago

CalDav New Event Naming: Loss-of-focus after click-and-drag creation

Categories

(Calendar :: Provider: CalDAV, defect)

Thunderbird 78
defect

Tracking

(thunderbird_esr78+ fixed, thunderbird86+ fixed)

RESOLVED FIXED
87 Branch
Tracking Status
thunderbird_esr78 + fixed
thunderbird86 + fixed

People

(Reporter: c.sie, Assigned: rnons)

References

(Regression)

Details

(Keywords: regression)

Attachments

(3 files, 1 obsolete file)

Attached image bugreport_final.gif (deleted) —

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

  1. Configure CalDav calendar (here: hosted on Nextcloud instance)
  2. Draw a new event in the calendar using click-and-drag, try to name it by typing immediately
  3. For comparison: Create local calendar. Repeat procedure.

Actual results:

The CalDav event is successfully created. However, almost immediately focus is lost and any already typed event name alongside it. The event then reverts to "Untitled" due to the interrupted naming. For comparison, the local calendar allows for seamless entering of the event name without interruption until manually saved.

The attached gif shows the different behaviour of the Caldav events in blue and the local calendar in pink. TB is run without any plugins.

Expected results:

CalDav Event Creation should allow for entering the event name.

Through extensive trial and error, I have found that the problem was introduced in between versions 78.5.1 (last version without the described bug) and 78.6.0 (which has the issue). I have tested this with the same CalDav Server on my Nextcloud instance for all versions, using the same profile. After switching back and forth between these two versions several times, I am confident that this is a bona fide bug and that it is entirely located in the application itself with no origin or persistence inside the profile. I will next investigate which file within omni.ja is driving the problem.

Through further testing I have identified the responsible file to be

omni.ja\modules\CalDavCalendar.jsm

When transplanting this file from the last working 78.5.1 into the omni.ja of 78.6.0, the issue with my nextcloud WebDav is resolved. Note: When testing, make sure to delete the StartupCache folder inside your profile in between each change to prevent cached omni.ja components from interfering.

By comparing the two files (see new bug attachment screenshot) I have determined that adding back the "return;" statement (which is present in 78.5.1 but missing in 78.6.0) below line 623 in CalDavCalendar.jsm of 78.6.0 is sufficient to restore functionality and fix the issue.

Whether this rough fix causes problems with other types of CalDav servers I cannot yet say. Maybe an actual Mozilla developer could help out here?

[bugzilla hadn't sent my comment]
In that this would be caused by https://hg.mozilla.org/comm-central/rev/d499974a1e21 - bug 1652984

Flags: needinfo?(remotenonsense)
Keywords: regression
Regressed by: 1652984

Thank you for your insight and consideration Magnus! More for the sake of my own learning and practice, I've generated a patch file (attached) in Mercurial which is adding back the putatively missing "return;" statement. Should this be inappropriate at this point, please excuse my rush.

In the meantime, I can report that manually adding the "return;" statement has permanently fixed the issue in my TB 78.7.0 (64bit) without any problems arising so far. I have also tested another CalDav server other than my own Nextcloud instance and observed the same behavior. Specifically, the CalDav connection to an account with all-inkl.com shows the same symptoms in the absence of the "return;" statement and is fixed after adding it back into CalDavCalendar.jsm inside of my omni.ja. So while this is still no exhaustive list of tested servers, it at least shows that not only Nextcloud is affected.

Attached patch 1685918.patch (deleted) — Splinter Review

Thanks c.sie, turns out adding back return is not enough, when importing an .ics file, the import dialog won't receive oncomplete event. This patch should fix both problems.

I made the following change in bug 1652984 because getUpdatedItem didn't work. Now I know it's because for a UID: a@b.c, the item id becomes a%40b.c, and in makeUri, the % is encoded again to %25. I didn't find where the @ in UID is encoded in the first place.

-          this.getUpdatedItem(parentItem, aListener);
-          return;
+          this.safeRefresh();
Assignee: nobody → remotenonsense
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(remotenonsense)
Attachment #9200559 - Flags: review?(geoff)
Attachment #9200559 - Flags: review?(geoff) → review+

Thank you very much for taking this on Ping! I've applied your patch locally and can confirm that it is solving the issue on my side. Thanks everyone!

Target Milestone: --- → 87 Branch

Comment on attachment 9200534 [details] [diff] [review]
Suggested Patch to add back the return statement

Thanks C.Sie. Marking this obsolete, but looking forward to patches from you for other issues you find in the future :)

Attachment #9200534 - Attachment is obsolete: true

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/b05e7b8d3811
Prevent double encoding CalDav URI. r=darktrojan

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED

Comment on attachment 9200559 [details] [diff] [review]
1685918.patch

[Approval Request Comment]
Regression caused by (bug #): bug 1652984
User impact if declined: When creating a calendar event by dragging, the name input loses focus when still typing
Testing completed (on c-c, etc.): c-c
Risk to taking this patch (and alternatives if risky): Low

Attachment #9200559 - Flags: approval-comm-esr78?
Attachment #9200559 - Flags: approval-comm-beta?

Comment on attachment 9200559 [details] [diff] [review]
1685918.patch

[Triage Comment]
Approved for beta

Attachment #9200559 - Flags: approval-comm-beta? → approval-comm-beta+

Comment on attachment 9200559 [details] [diff] [review]
1685918.patch

[Triage Comment]
Approved for esr78

Attachment #9200559 - Flags: approval-comm-esr78? → approval-comm-esr78+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: