Closed Bug 1593711 Opened 9 months ago Closed 2 months ago

Search/Filtering in TASKS not working when Incomplete Tasks is selected

Categories

(Calendar :: Tasks, defect)

Lightning 68
defect
Not set
normal

Tracking

(thunderbird78 fixed)

RESOLVED FIXED
Thunderbird 78.0
Tracking Status
thunderbird78 --- fixed

People

(Reporter: steve.hesse, Assigned: darktrojan)

References

Details

(Keywords: regression)

Attachments

(3 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362

Steps to reproduce:

I was recently auto upgraded from Thunderbird 60.9.0 to 68.1.2, and the update was successful. I discovered a feature that no longer works. On the "Tasks" tab in Lightning, when you select "Incomplete Tasks" (under SHOW in the left sidebar), and then try to filter tasks in the search bar (aka Ctrl+Shift+K), that filtering is ignored entirely. However, if under SHOW, you select any other choice (like All, Today, etc), then the search/filtering works.

Actual results:

Search/filtering is ignored entirely. The display of Incomplete Tasks is not filtered.

Expected results:

Search/filtering should display only the tasks that contain the search sequence.

Component: Untriaged → Tasks
Product: Thunderbird → Calendar
Version: 68 → unspecified

I see that at the moment this Bug's status officially is only Unconfirmed, so i wish to add my own independent confirmation. I have already posted about this with full description details here:

  1. https://forum.manjaro.org/t/ive-had-to-downgrade-thunderbird-68-back-to-60/111894?u=kdemeoz
  2. https://forum.manjaro.org/t/ive-had-to-downgrade-thunderbird-68-back-to-60/111894/7?u=kdemeoz

Key Points

  1. If the TB/L database contains only a tiny number of Tasks [eg, i tested a clean installation of 68.x with only 4 new/dummy tasks], all the Tasks filters [ie, including "Incomplete"] still work. The bug manifests somehow once the total tasks quantity exceeds some threshold [given i have several hundreds, i seem to have sadly crossed this threshold].
  2. The bug appeared with the update from 60.x to 68.x.
  3. The bug manifests in all dot-releases so far of v68.
  4. "Find" continues to work in Calendar, & in ALL the OTHER Task views EXCEPT for "Incomplete Tasks".
  5. The Bug seems slightly variable in that some days the "Incomplete Tasks" view shows no entries at all, whereas other days it inherits the previous filter view. However, in all cases Find via the "Filter Tasks" field when in the "Incomplete Tasks" view, never does anything [in 68; but is always good in 60].

I agree that this could be related to the number of Incomplete Tasks. I have about 150. But if you change the view to "All", the filtering works, and I must have in excess of 1000 tasks under the "All" view (Complete and Incomplete Tasks). I have regressed to version 60 until this is fixed.

Disappointing, TB 68.3.0-1 still has not fixed this bug.

Maybe Geoff knows how this regressed, if it in fact is a regression

Flags: needinfo?(geoff)

I don't see this. I've found a similar bug on our development versions, but I found the change that caused it and that change did not land on 68. I've tried all sorts of things on a list of 1800+ tasks and none of them reproduced this bug.

I wonder if there's something unusual about a particular task in your database that might cause something to fail. That would be weird but not impossible.

Flags: needinfo?(geoff)

(In reply to Geoff Lankow (:darktrojan) from comment #5)

I don't see this. I've found a similar bug on our development versions, but I found the change that caused it and that change did not land on 68. I've tried all sorts of things on a list of 1800+ tasks and none of them reproduced this bug.

Hi Geoff, that's disappointing news that you cannot reproduce it, yet there's at least two of we users independently experiencing it. Bummer.

(In reply to Geoff Lankow (:darktrojan) from comment #5)

I wonder if there's something unusual about a particular task in your database that might cause something to fail. That would be weird but not impossible.

I have also wondered this, however i have no idea at all how i might investigate & verify/eliminate this. I have way waaaaaaaaaaaay too many Tasks for a simple trial & error method to be reasonable. Is there some database integrity tool/test i could use which might help? Would you have any alternative suggestions pls?

Hi, I'm also affected by the bug after my last upgrade to Thunderbird 68.2.2 (64-bit) on Ubuntu 18.04 LTS.

Observations:

  • "incomplete tasks" either doesn't show anything, or just keeps showing whatever was previously selected (e.g. "current tasks")

  • Filtering doesn't work for "incomplete tasks" but works with other selections.

  • Sorting the tasks by clicking columns titles seems to still work even for incomplete tasks if another one was selected before (e.g. "current tasks"), even though the list of tasks shown is not correct.

In case any of the following is relevant:

  • I have several years of tasks, probably a few hundreds.

  • I use repeating tasks quite a lot, maybe it's related?

  • I have some tasks which include accentuated characters (doubt char encoding has anything to do with it though)

Don't hesitate to ask me if I can provide any other detail.

Hi Erwan - apart from your final dot-point, each of your listed symptoms & circumstances matches mine.

I forgot to include this in my original post, & cannot see it could possibly be pertinent, but shall mention it now just in case. Though i have used TB for ~4 years in Linux, for more than 20 years prior my PIM was instead Microsoft Schedule+ --> MS Outlook 97 --> MS Outlook 2010. In ~2014 or 2015 i migrated my Outlook data to Thunderbird in Windows7 [having already changed from Win7 to Linux as my primary OS] so that i could then begin using this TB data in Linux. Could there have been some vestigial MS timebomb left-over?

TL;DR = my current Linux TB data originated in Win7 MS products.

Important update after my report 1 week ago: today I noticed that everything seems to work normally including "incomplete tasks", even though I didn't do anything special: no update, no particular change in my configuration.... I really can't think of anything explaining that things went back to normal (I added/modified a few tasks but I had tried that before without success). Well, let's just hope it stays this way, I'll report if the problem comes back.

@Kadee thanks for your response, good luck!

Great albeit mystifying news for you Erwan!. Unfortunately, no change here; Incomplete Tasks remain broken per my original description.

I was on Debian when they upgraded to Thunderbird 68 and got this behavior. I was on a 4 year old profile. That profile had never been on Windows or any other operating system. I had used it at times on various linux distributions. Now I'm on a brand new profile on Debian. I get the disappearing incomplete tasks intermittently. Mostly they are present but sometimes they just disappear. When this happens if I switch to another filter such as "all" that filter will work but when I switch back to incomplete tasks the previous filter remains. I have only 15 or so tasks.

(In reply to Geoff Lankow (:darktrojan) from comment #5)

I wonder if there's something unusual about a particular task in your database that might cause something to fail. That would be weird but not impossible.
My tasks are very simple. I check the start date box, set a date, and fill in the title. Sometimes I might put in a description. Some of my tasks are repeating. I almost never check the due date box but from time to time I do after the task is a few days old and I want to turn the task red so that I get it done. That's it.

Good morning!
I note the same behavior, unfortunately I can't report since it happen, but 3 months ago could be right;

  • actually I use Thunderbird 68.6.0 64Bit on Windows 10; i switched from TB 32Bit to TB 64 Bit some months ago, could this be cause?
  • my calendars are on the network using CalDAV and RadiCale on my Linux server - could this be the cause?

Regarding JeiEff's comment: I do use TB 64-bit, but I never used the 32-bit version, so switching doesn't seem related. And for calendaring, I use Lightning 6.2.5, so the calendar differences wouldn't seem to be related either. Just another data point...

I also have this on multiple computers, mostly with Linux. Lighting on TB 60 was OK (but horribly slow - 10 CalDav calendars here), Lightning on TB 68 is much faster doesn't filter unfinished tasks (the unfinished view is the only practical one in my use case). One step forward, one step back. ;-)

Anyway, in my case all the tasks are on a couple of CalDav calendars, maybe that's the defining factor?

As an update, after entering even one letter in the filter box, the following appears in the error console:

NS_NOINTERFACE: Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsISupports.QueryInterface] calFilter.js:814
getNextOccurrence chrome://calendar/content/calFilter.js:814
forEach self-hosted:266
getNextOccurrence chrome://calendar/content/calFilter.js:812
getOccurrences chrome://calendar/content/calFilter.js:861
onGetResult chrome://calendar/content/calFilter.js:903
queueItems jar:file:///home/domin/.thunderbird/qfe8veh6.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi!/components/calStorageCalendar.js:777
getItems_ jar:file:///home/domin/.thunderbird/qfe8veh6.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi!/components/calStorageCalendar.js:962
getItems jar:file:///home/domin/.thunderbird/qfe8veh6.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi!/components/calStorageCalendar.js:691
postPone resource://calendar/modules/calUtils.jsm:241
getItems jar:file:///home/domin/.thunderbird/qfe8veh6.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi!/components/calStorageCalendar.js:690
funcName resource://calendar/calendar-js/calCachedCalendar.js:973
getItems chrome://calendar/content/calFilter.js:942
execute chrome://calendar/content/calendar-task-tree.js:489
refreshFromCalendar chrome://calendar/content/calendar-task-tree.js:501
refresh chrome://calendar/content/calendar-task-tree.js:524
forEach self-hosted:266
refresh chrome://calendar/content/calendar-task-tree.js:524
doUpdateFilter chrome://calendar/content/calendar-task-tree.js:600
updateFilter chrome://calendar/content/calendar-task-tree.js:605
taskViewUpdate chrome://calendar/content/calendar-task-view.js:343
oncommand chrome://messenger/content/messenger.xul:1
fireCommand chrome://global/content/elements/search-textbox.js:241
NS_NOINTERFACE: Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsISupports.QueryInterface] 2 calFilter.js:814
NS_NOINTERFACE: Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsISupports.QueryInterface] calFilter.js:814
getNextOccurrence chrome://calendar/content/calFilter.js:814
forEach self-hosted:266
getNextOccurrence chrome://calendar/content/calFilter.js:812
getOccurrences chrome://calendar/content/calFilter.js:861
onGetResult chrome://calendar/content/calFilter.js:903
queueItems jar:file:///home/domin/.thunderbird/qfe8veh6.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi!/components/calStorageCalendar.js:777
getItems
jar:file:///home/domin/.thunderbird/qfe8veh6.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi!/components/calStorageCalendar.js:962
getItems jar:file:///home/domin/.thunderbird/qfe8veh6.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi!/components/calStorageCalendar.js:691
postPone resource://calendar/modules/calUtils.jsm:241
getItems jar:file:///home/domin/.thunderbird/qfe8veh6.default/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}.xpi!/components/calStorageCalendar.js:690
funcName resource://calendar/calendar-js/calCachedCalendar.js:973
getItems chrome://calendar/content/calFilter.js:942
execute chrome://calendar/content/calendar-task-tree.js:489
refreshFromCalendar chrome://calendar/content/calendar-task-tree.js:501
refresh chrome://calendar/content/calendar-task-tree.js:524
forEach self-hosted:266
refresh chrome://calendar/content/calendar-task-tree.js:524
doUpdateFilter chrome://calendar/content/calendar-task-tree.js:600
updateFilter chrome://calendar/content/calendar-task-tree.js:605
taskViewUpdate chrome://calendar/content/calendar-task-view.js:343
oncommand chrome://messenger/content/messenger.xul:1
_fireCommand chrome://global/content/elements/search-textbox.js:241

(In reply to Dominik Wnęk from comment #20)

I also have this on multiple computers, mostly with Linux. Lighting on TB 60 was OK (but horribly slow - 10 CalDav calendars here), Lightning on TB 68 is much faster doesn't filter unfinished tasks (the unfinished view is the only practical one in my use case). One step forward, one step back. ;-)

Anyway, in my case all the tasks are on a couple of CalDav calendars, maybe that's the defining factor?

I'm using the Provider for Google Calendar extension. However my tasks are on the Home calendar.

Hi,

Seeing the last few reports made me realize that this issue might have something to do with synchronizing calendars on the network. I also use CalDav and I had the issue show up from time to time since my last report. So far it always goes away at a later time.

I'm wondering if some kind of network sync issue could cause an inconsistency which "freezes" the showing of incomplete tasks? I'm thinking something like maybe adding a task when not connected to the network on machine A, then connecting from machine B and changing a few things, then when reconnecting from machine A receiving changes from B which turn out to be incompatible with the task previously added offline on A?? I'm just imagining a scenario, I don't have evidence for that.

I don't use CalDav or any network sync capabilities and still have the reported problem. So for my two cents, it's not related to that...

(In reply to SteveH from comment #24)

I don't use CalDav or any network sync capabilities and still have the reported problem. So for my two cents, it's not related to that...

Ditto here, so i agree with you.

10/5/20: Still NFG with latest update (68.7.0-2 -> 68.8.0-1).

Duplicate of this bug: 1598855
Duplicate of this bug: 1602572
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → All
Hardware: Unspecified → All
Version: unspecified → Lightning 68
Duplicate of this bug: 1615711
Duplicate of this bug: 1598801
Duplicate of this bug: 1606639

It seems the error shown in the error console has its origin in https://hg.mozilla.org/comm-central/rev/333bacc415976d61ca918d882e00fa9ead2a4051 (bug 1528133). Not every change there has been done with the awareness of having to handle both, events and todos.

Probably some more code like

if (next instanceof Ci.calIEvent) {
    next.QueryInterface(Ci.calIEvent);
} else if (next instanceof Ci.calITodo) {
    next.QueryInterface(Ci.calITodo);
}

to properly facilitate startDate or entryDate has to be used, especially in calFilter.js:800 and :813 for this issue.

Geoff, you have been the author of the commit probably causing this issue. Maybe you can have a look or pass it on to someone more appropriate.

Flags: needinfo?(geoff)
Duplicate of this bug: 1610794

Yes, that does appear to be the case. In fact I think those QueryInterfaces are unnecessary.

I've finally been able to reproduce this. It requires a repeating task, where some instances have been completed and some have not. I have a fix and I'm working on adding it to the test suite, but the test I'm adding to has been very unreliable in the last few days for some reason, so I'll have to fix it first.

Assignee: nobody → geoff
Status: NEW → ASSIGNED
Flags: needinfo?(geoff)

(In reply to Geoff Lankow (:darktrojan) from comment #34)

I've finally been able to reproduce this. It requires a repeating task, where some instances have been completed and some have not. I have a fix ...

I am so happy to read this!

Remove the two QIs. IIRC they were added to solve a problem that went away, but we decided not to back out the first solution as it wasn't harming anything (except it was).

Attachment #9157810 - Flags: review?(paul)
Attachment #9157810 - Flags: approval-calendar-esr?(paul)
Attachment #9157810 - Flags: approval-calendar-beta?(paul)

This adds a repeating task (with one instance completed) to the tasks test. While here I've converted from is to Assert.equal because it's better.

Attachment #9157811 - Flags: review?(paul)
Attachment #9157811 - Flags: approval-calendar-beta?(paul)
Comment on attachment 9157810 [details] [diff] [review]
1593711-remove-qis-1.diff

Review of attachment 9157810 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM.  I reproduced the issue and this patch fixes it.
Attachment #9157810 - Flags: review?(paul)
Attachment #9157810 - Flags: review+
Attachment #9157810 - Flags: approval-calendar-esr?(paul)
Attachment #9157810 - Flags: approval-calendar-esr+
Attachment #9157810 - Flags: approval-calendar-beta?(paul)
Attachment #9157810 - Flags: approval-calendar-beta+
Comment on attachment 9157811 [details] [diff] [review]
1593711-repeating-task-test-1.diff

Review of attachment 9157811 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good and the test passed when I ran it.  Would you remind me why is "Assert.equal" better than "is" again?  I'd like to add it to our mochitests docs.
Attachment #9157811 - Flags: review?(paul)
Attachment #9157811 - Flags: review+
Attachment #9157811 - Flags: approval-calendar-beta?(paul)
Attachment #9157811 - Flags: approval-calendar-beta+

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/2b976ecaac38
Remove extraneous QueryInterface calls that broke task filtering. r=pmorris
https://hg.mozilla.org/comm-central/rev/438eb40a8d9d
Test task filtering with repeating tasks. r=pmorris

Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 79

"79" does not mean TB 79 i hope ... given atm we're on 68.9.0 ?

Target Milestone: 79 → 78

78 - 68 = 😢

One step at a time Kadee.

Geoff or Paul, can you rebase this for 68 please?

Flags: needinfo?(paul)
Flags: needinfo?(geoff)
Flags: needinfo?(paul)
Flags: needinfo?(geoff)
Attachment #9160226 - Flags: review+
Attachment #9160226 - Flags: approval-calendar-esr+

I'm happily giggling like a loon now -- it works, it finally works once more! Thank you to all involved; the loss of that function has been hard on my workflow for months, so this success is really welcome.

I wish to thank all the people involved too - Great Work, Great Community!

Great to hear this is fixed! Being just a stupid user, and not a developer, how do I deploy this patch, or do I still have to wait for TB release 78? I'm still stuck on release 60 until I can get this fix. Thanks....

Thanks everybody!

(In reply to SteveH from comment #50)

... how do I deploy this patch, or do I still have to wait for TB release 78?

The patch is incorporated in v68.10.0, which is already available in the ArchLinux repos, hence i got it [my] yesterday. For other distros, & presumably also Windows, i imagine it will become available any time now.

I just upgraded to TB 68.10.0 and verified that this issue is fixed. Thank you to everyone that helped isolate and fix this issue, particularly Geoff....

You need to log in before you can comment on or make changes to this bug.