CalDav New Event Naming: Loss-of-focus after click-and-drag creation
Categories
(Calendar :: Provider: CalDAV, defect)
Tracking
(thunderbird_esr78+ fixed, thunderbird86+ fixed)
People
(Reporter: c.sie, Assigned: rnons)
References
(Regression)
Details
(Keywords: regression)
Attachments
(3 files, 1 obsolete file)
(deleted),
image/gif
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
patch
|
darktrojan
:
review+
wsmwk
:
approval-comm-beta+
wsmwk
:
approval-comm-esr78+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0
Steps to reproduce:
- Configure CalDav calendar (here: hosted on Nextcloud instance)
- Draw a new event in the calendar using click-and-drag, try to name it by typing immediately
- 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?
Comment 3•4 years ago
|
||
[bugzilla hadn't sent my comment]
In that this would be caused by https://hg.mozilla.org/comm-central/rev/d499974a1e21 - bug 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.
Assignee | ||
Comment 5•4 years ago
|
||
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();
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
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!
Updated•4 years ago
|
Comment 7•4 years ago
|
||
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 :)
Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/b05e7b8d3811
Prevent double encoding CalDav URI. r=darktrojan
Assignee | ||
Comment 9•4 years ago
|
||
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
Comment 10•4 years ago
|
||
Comment on attachment 9200559 [details] [diff] [review]
1685918.patch
[Triage Comment]
Approved for beta
Comment 11•4 years ago
|
||
bugherder uplift |
Thunderbird 86.0b2:
https://hg.mozilla.org/releases/comm-beta/rev/784d8114f9f8
Comment 12•4 years ago
|
||
Comment on attachment 9200559 [details] [diff] [review]
1685918.patch
[Triage Comment]
Approved for esr78
Comment 13•4 years ago
|
||
bugherder uplift |
Thunderbird 78.8.0:
https://hg.mozilla.org/releases/comm-esr78/rev/82df66b9dccf
Description
•