Event shown twice in unifinder after editing / still shown after deleting
Categories
(Calendar :: Calendar Frontend, defect)
Tracking
(Not tracked)
People
(Reporter: ssitter, Unassigned)
References
(Regression)
Details
(Keywords: regression)
Attachments
(3 files)
1.20 MB,
application/x-xpinstall
|
Details | |
1.62 KB,
patch
|
Details | Diff | Splinter Review | |
330.52 KB,
patch
|
Details | Diff | Splinter Review |
Thunderbird 68.0a1 (20190416083948) + Lightning 7.0a1
History:
Open calendar week view. Open unifinder and set it to show the current week, e.g. by selecting 'Events in the next 14 days' filter. Create an event by drag and drop in week view. Observe that is is shown in unifinder.
Action:
- Drag and drop the event to a different date/time. Or edit the event and change e.g. the title.
- Delete the event
Error:
- Unifinder shows event twice. Once with old title/time and once with new title/time.
- Event is still shown. Only the entry with the old title/time is removed.
Reporter | ||
Updated•6 years ago
|
Comment 1•6 years ago
|
||
See also Bug 1502923 Comment 66... fyi
Comment 2•6 years ago
|
||
FYI, I have just tested following instructions and cannot reproduce the issue with TB 67.0b1 and LT 6.9 manually patched with patch.v03 as submitted in bug Bug 1502923... so this regression might come from somewhere else... possibly... to be doubled checked and confirmed...
Reporter | ||
Comment 3•6 years ago
|
||
Regression range:
Works in Thunderbird 68.0a1 (20190411084211)
Fails in Thunderbird 68.0a1 (20190412102825)
Changes:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=1ce8576d29ec4e7ec92faec84b082ff59e18f0a8&tochange=cd367a28aeb935df9b62bfb563980fdfc1f3905a
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b5bcfc2617667e3fc7a095b262b80377b2542446&tochange=a632dfa60af6edd4f7dd03d404d898b6222b56c3
Comment 4•6 years ago
|
||
Geoff,
Have you observed such regression as per your testing following patch v03 submitted in Bug 1502923 and pushed to LT 7?
Are you able to identify any other changes (as per links provided by Stephan in previous comment) that could explain the regression observed in this bug?
I only use beta version of TB so I won't be able to check before next beta is out... but may be nice to fix before then... in measure of possible... if you got a chance to have a look at it... to at least confirm issue and identify possibly root cause...
Regards,
Comment 6•6 years ago
|
||
I can confirm this does happen and it's very likely to be caused by bug 1502923.
Comment 7•6 years ago
|
||
It could also be caused by other code changes made between Lightning 6.9 and 7.0a1 other than bug 1502923 patch.v03 especially changed affecting the calendar UI features...
The patch.v03 was indeed created and tested with LT 6.9 on TB 67.0b1 and I cannot reproduce issues reported in this bug with this environment...
Also other changes between TB 67.0b1 and TB 68.0a1 could have had side effects as well possibly...
How to get Lightning .xpi extension for:
- Working Thunderbird 68.0a1 (20190411084211)
and - Fails in Thunderbird 68.0a1 (20190412102825)
...to compare code changes with Lightning 6.9?
Reporter | ||
Comment 8•6 years ago
|
||
I have already identified the regression range to a single day. The change from Bug 1502923 seems to be the only change in calendar code during that day. And it changed the unifinder behavior that is now working incorrectly.
There are no dedicated .xpi files anymore. For testing and finding regression range I use the Thunderbird nightly builds (https://archive.mozilla.org/pub/thunderbird/nightly/2019/04/). I always create a new profile to ensure that I'm using the Lightning package shipped with this specific Thunderbird build.
Reporter | ||
Updated•6 years ago
|
Comment 9•6 years ago
|
||
Hi Stefan,
Would you be able to confirm the following when you encountered the issue:
-
You setup a network caldav calendar in a new profile
-
What are your calendar properties, would you be able to send a printscreen? I am thinking maybe you have the offline option turned ON which may potentially be the root cause of issue perhaps... just a possible hint... if that is the case would you be able to turn it OFF, restart TB and try again?
-
What is your environment and version (apart from TB and LT) you tested and got the issue?
Regards,
Reporter | ||
Comment 10•6 years ago
|
||
I setup nothing. I used the default storage calendar that is created automatically in a new profile.
Comment 11•6 years ago
|
||
I activated offline mode on my calendar in my test environment and still cannot reproduce the issue you encounter so my hint was wrong, back to square one... some other code change between TB 67.0b1 and LT 6.9 manually patched with patch.v03 and Thunderbird 68.0a1 (20190416083948) + Lightning 7.0a1 which include the patch, must have an impact some how on the patch causing the regression...
Comment 12•6 years ago
|
||
Stefan,
In the unifinder view (list of events):
-
are the items sorted by any column header in your case (e.g Title) or not (default)? If yes, which column?
-
if you sort by Title header column and then try again do drag and drop move of an event within the calendar UI, does the duplicate still appears as before in the unifinder list?
-
in the selection box, which option is currently selected in your case (e.g All Event, Current Selected Day, etc...)?
Cheers,
Reporter | ||
Comment 13•6 years ago
|
||
I'm a little surprise that you are not able to reproduce. For me its just creating a new profile, accept Lightning to be installed and than proceed with Thunderbird and Lightning default setting and the steps given in Comment #0. No additional configuration, no additional calendars, no changes to the unifinder settings or anything else required.
Comment 14•6 years ago
•
|
||
(In reply to Stefan Sitter [:ssitter] from comment #13)
I'm a little surprise that you are not able to reproduce. For me its just creating a new profile, accept Lightning to be installed and than proceed with Thunderbird and Lightning default setting and the steps given in Comment #0. No additional configuration, no additional calendars, no changes to the unifinder settings or anything else required.
I just tested using the STR from Comment #0 and can reproduce the problem with a test profile and my production profile.
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.0a1 BuildID: 20190423080328
Also reproducible using Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.0a1
Comment 15•6 years ago
|
||
FYI, the link below shall list the changes that occurred between last beta (TB 67.0b1 and LT 6.9) more likely build on 1st April 2019 (according to source tarball creation date) where issue does not happens after applying Bug 1502923 patch.v03 manually, and Thunderbird 68.0a1 (20190412102825) + LT 7.x (which include the patch) where issue starts to occur...
https://hg.mozilla.org/comm-central/pushloghtml?startdate=2019-04-01&enddate=2019-04-13
Obviously one of those changes affected the patch somehow... there seems to be multiple changes in the calendar code in the course of April... as per each file revision logs... I can't seems to be able to get one list of all the diff affecting those files in one request via the web UI of the hg repository... I cannot get a diff between LT6.9 and LT 7.x as I don't have access to LT 7.x as .xpi file) to know the differences applied as a starting point... so difficult to know at the moment what could have caused the regression...
Comment 16•6 years ago
|
||
FYI, find attached LT 6.9 extension including patch.v03 that I use for testing... on TB 67.0b1...
@Stephan,
With Thunderbird 68.0a1 (20190412102825) which is currently failing at your end would you be able to do the following:
- Create a new profile
- Make sure to not activate calendar feature
- Go to Add-ins and remove lightning extension (may be added but disabled, make sure it is removed)
- Restart TB and reopen this new profile make sure extension has been removed
- Then add Lightning extension from file attached (which is version 6.9 including patch)
- Once added you can check version of the extension it should show 6.9rl as version
- Make sure to set the extension not to auto-update
- Then enable it if not already enabled
- Then add network calendar as you previously did and test again
What result do you get this time?
Regards,
Comment 17•6 years ago
|
||
FYI, .xpi extension attached in my previous comment is LT 6.9 extension with patch applied as per diff attached...
Reporter | ||
Comment 18•6 years ago
|
||
I'll not install custom builds. Maybe you should start testing with the official builds?
Comment 19•6 years ago
|
||
(In reply to Stefan Sitter [:ssitter] from comment #18)
I'll not install custom builds. Maybe you should start testing with the official builds?
Please note that I am not a TB developer but a simple TB user trying to help fixing a performance issue that has been plaguing TB for years. As such I cannot go further that using TB beta version on my machine at the moment to provide some help and a lot of my time.
As you already run the daily build in your testing environment I thought (wrongly perhaps) you may be able to provide a little help in trying to sort the regression you raised in following my instructions in Comment 16 (not much asked I believe) to highlight if issue is within TB core code or within LT code introduced since last beta.
The Bug 1502923 patch.v03 is a pretty small patch (with apparently a big positive effect) and a very clear regression due to the patch "conflicting" with additional code introduce in TB since last beta.
I am not asking you to fix the regression but to re-run your test with the previous LT 6.9 version including the small added patch... that is all...
There is a two weeks windows before next beta so it would be great if the regression could be sorted before then... test requested in Comment 16 may help narrow down the root cause of it...
A small help would be much appreciated... we are very close to sorting a very bad performance issue in TB due to LT... it would be regrettable to miss this opportunity... before next beta...
Thank you for understanding and any help you can provide.
Comment 20•6 years ago
|
||
(In reply to Stefan Sitter [:ssitter] from comment #3)
Regression range:
Works in Thunderbird 68.0a1 (20190411084211)
Fails in Thunderbird 68.0a1 (20190412102825)
Find attached what seemed to have changed between LT 6.9 (from TB 67.0b1) and LT 7.0a1 (from TB 68.0a1 20190412102825)... as per extracted code from .xpi extension available in source code for each version.
One of those changes caused the issue... maybe something is no longer triggered that was triggered previously... or vice-versa... and some how "conflict" with patch.v03...
Though I now suspect it may be just a view issue (something not refreshed properly) rather than an underlying data issue.
Anyone involved in the code change would be welcome to review and advice on what could be causing the regression...
There may also be some performance regression that may need to be looked at... partially reverting good result obtained with patch.v03 on TB 67.0b1.
Comment 21•6 years ago
|
||
Statistics with one network calendar (CalDav) with ~4000 items - no email setup
I did some extra tests and here are the results... the calendar seems to be loading into two phases...
- Phase1 - Loading data via multiple network requests + and filling UI with items for each request
- Phase2 - After network data loading has completed all items disappear from calendar week view for a long period of time during which calendar is still not available.
Connection Speed in use for those tests
Client speed (ADSL): ~7.86 Mbit/s Download | ~0.80 Mbit/s Upload
Server speed (FTTC): ~74.05 Mbit/s Download | ~18.28 Mbit/s Upload
The same calendar (.ics file) can be downloaded manually in full with all items via one GET request in about ~2sec (as tested in Firefox 66.0.3).
TB 67.0b1 + TB 6.9 + patch.v03 applied manually + no Offline Support + no Show Reminders
- Phase1 DevTools Network loading statistics: 43 requests | 5.98MB/6MB transferred | Finish: 1mn 4sec
- Phase2 View Refreshing (after network data has fully loaded, calendar items disappear in week view for a period of time): ~8sec
Total = ~1mn 12sec till calendar is accessible/usable via UI <-- still a bad number but the best we can get at the moment.
TB Nightly 68.0a1 2019-04-12-10-28-25-comm-central-l10n (which include LT 7.0a1 + patch.v03 already) + no Offline Support + no Show Reminders
- Phase 1 DevTools Network loading statistics: 43 requests | 5.98MB/6MB transferred | Finish: 1mn 74sec <-- 70 seconds more than previous test due to delay between network requests like a brief noticeable pause
- Phase 2 View Refreshing (after network data has fully loaded, calendar items disappear completely in week view for a period of time): ~45sec <-- 35 seconds more than previous test
Total = ~2mn 19sec till calendar is accessible/usable via UI <-- 1mn more than previous test
Those test results means that in addition of...
-
...this regression bug is unlikely due to patch.v03 but more likely due to an UI view issue (changing unfinder view option from "Events in the next 7 days" [default view] to "Event in current view" and back to "Events in the next 7 days" fix the view issue) as opposed to an underlying data issue...
-
...there is also a regression in term of performance (increase delay till calendar is usable by +1mn an increase of +100% twice as much!!!) but with new code introduced in Lightning apart from patch.v03, this would need to be addressed somehow...
Conclusion
In light of those results, I don't think removing patch.v03 would be the best way to fix regressions observed... as they are unlikely due to it... though it could have been a trigger somehow... due to other code changes highlighted in Comment 20.
Without patch.v03, tests results above would be even much much much worth...
Comment 22•6 years ago
|
||
Another note about this bug regression, with Thunderbird 68.0a1 (build 20190412102825) when editing items from calendar week view, for example changing the Title of an event, after saving, the event appears with CORRECT new title in calendar week view AND unifinder view (event list) before the event DISAPPEAR from the calendar week view (only the one modified) during which the event is again somehow updated in unifinder with the previous data (e.g Title) and after a long while the event reappear with correct new Title in calendar week view but still with old outdated details info in unifinder (event list).
Workaround:
To fix the issue, you can switch view back and force in unifinder (event list) via selection box (e.g from "Events in the next 7 days" [default view] to "Event in current view" and back to "Events in the next 7 days"), this would refresh the view and the item will then appear correctly in unifinder with correct updated data (e.g Title).
patch.v03 only affect the sorting and indexing of items in unifinder but not the underlying item data set in anyway so it cannot possibly be the root cause of the regression.
Reporter | ||
Updated•6 years ago
|
Comment 23•6 years ago
|
||
Fixed by backout in bug 1502923. Before the backout I verified manually that the backout fixes the issue reported here.
Description
•