Closed Bug 1545042 Opened 5 years ago Closed 5 years ago

Event shown twice in unifinder after editing / still shown after deleting

Categories

(Calendar :: Calendar Frontend, defect)

Product:
Calendar
Component:
Calendar Frontend
Version:
Lightning 68
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: ssitter, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(3 files)

{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi
1.20 MB, application/x-xpinstall
Details
diff.LT.6.9.with.patch.txt
1.62 KB, patch
Details | Diff | Splinter Review
diff_TB67.0b1.LT6.9_TB68.0a1.LT7.0a1.2019-04-12-10-28-25.txt
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:

  1. Drag and drop the event to a different date/time. Or edit the event and change e.g. the title.
  2. Delete the event

Error:

  1. Unifinder shows event twice. Once with old title/time and once with new title/time.
  2. Event is still shown. Only the entry with the old title/time is removed.
Keywords: regression

See also Bug 1502923 Comment 66... fyi

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...

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,

Flags: needinfo?(philipp)
Flags: needinfo?(geoff)

Not sure what information I can provide here.

Flags: needinfo?(philipp)

I can confirm this does happen and it's very likely to be caused by bug 1502923.

Flags: needinfo?(geoff)

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?

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.

Blocks: 1502923
No longer blocks: 1502923
Regressed by: 1502923

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,

Flags: needinfo?(ssitter)

I setup nothing. I used the default storage calendar that is created automatically in a new profile.

Flags: needinfo?(ssitter)

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...

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,

Flags: needinfo?(ssitter)

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.

Flags: needinfo?(ssitter)

(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

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...

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,

Flags: needinfo?(ssitter)

FYI, .xpi extension attached in my previous comment is LT 6.9 extension with patch applied as per diff attached...

I'll not install custom builds. Maybe you should start testing with the official builds?

(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.

(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.

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...

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.

Flags: needinfo?(ssitter)

Fixed by backout in bug 1502923. Before the backout I verified manually that the backout fixes the issue reported here.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 7.0
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: