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

Status: RESOLVED FIXED

(Calendar :: Tasks, defect)

Description

[SteveH]

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.

Comment 1

[Kadee]

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

Comment 2

[SteveH]

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.

Comment 3

[Kadee]

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

Comment 4

[Wayne Mery (:wsmwk)]

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

Comment 5

[Geoff Lankow (:darktrojan)]

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.

Comment 6

[Kadee]

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

Comment 7

[Erwan]

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.

Comment 8

[Kadee]

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.

Comment 9

[Erwan]

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!

Comment 10

[Kadee]

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

Comment 11

[Donald]

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.

Comment 12

[Donald]

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

Comment 13

[Kadee]

Tonight, Manjaro Stable-branch update:

thunderbird                        68.3.1-1        68.4.1-0.1

Still broken. No wonder really, i suppose, given Mozilla seems to be ignoring it:

 Status:   UNCONFIRMED

Abundant profanities. :-(

Comment 14

[Kadee]

thunderbird 68.4.1-1 > 68.4.2-1 ... but bug still not fixed :-(

Comment 15

[Kadee]

Ditto 68.5.0.

Comment 16

[Ben]

Hi,

I've got the same problem on windows 10 with thunderbird 68.6.0 (32-bits)

Comment 17

[Kadee]

Yep, ditto here; 68.6.0 [64 bit] in Manjaro continues this unsolved bug. :-(

Comment 18

[JeiEff]

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?

Comment 19

[SteveH]

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

Comment 20

[Dominik Wnęk]

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?

Comment 21

[Dominik Wnęk]

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

Comment 22

[Donald]

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

Comment 23

[Erwan]

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.

Comment 24

[SteveH]

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

Comment 25

[Kadee]

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

Comment 26

[Kadee]

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

Comment 32

[Martin Schröder [:mschroeder]]

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.

Comment 34

[Geoff Lankow (:darktrojan)]

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.

Comment 35

[Kadee]

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

Comment 36

[Geoff Lankow (:darktrojan)]

Attachment: 1593711-remove-qis-1.diff

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

Comment 37

[Geoff Lankow (:darktrojan)]

Attachment: 1593711-repeating-task-test-1.diff

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.

Comment 38

[Paul Morris [:pmorris]]

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.

Comment 39

[Paul Morris [:pmorris]]

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.

Comment 40

[Pulsebot]

Pushed by [e-mail]:
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

Comment 41

[Kadee]

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

Comment 42

[Rob Lemley [:rjl]]

Thunderbird 78.0b3:
https://hg.mozilla.org/releases/comm-beta/rev/5e938016a48a
https://hg.mozilla.org/releases/comm-beta/rev/be0f858d8172

Comment 43

[Kadee]

78 - 68 = 😢

Comment 44

[Geoff Lankow (:darktrojan)]

One step at a time Kadee.

Comment 45

[Rob Lemley [:rjl]]

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

Comment 46

[Geoff Lankow (:darktrojan)]

Attachment: 1593711-remove-qis-esr.diff

Comment 47

[Rob Lemley [:rjl]]

Thunderbird 68.10.0:
https://hg.mozilla.org/releases/comm-esr68/rev/6a7c26eb22bf

Comment 48

[Kadee]

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.

Comment 49

[JeiEff]

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

Comment 50

[SteveH]

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

Comment 51

[Donald]

Thanks everybody!

Comment 52

[Kadee]

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

Comment 53

[SteveH]

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

Comment 54

[Jorg K (CEST = GMT+2)]

This shows up in my query for bugs needing TB 78 uplift, bug it was originally fixed in TB 78, so let's use this trick: releases/comm-esr78/rev/

Comment 55

[nath-oedek]

Gear Jorg, thank you for your suggestion. I am going to test it and give my results to you
Detlef

Comment 56

[Jorg K (CEST = GMT+2)]

What's the question, Wayne? It's all good here, as far as I can see.

Comment 57

[nath-oedek]

Dear Jorg, I tested, everything is o.k.
Regards
Detlef

Comment 58

[gbl954]

this bug has resurfaced in 84.0.1

Comment 59

[Martin Schröder [:mschroeder]]

(In reply to gbl954 from comment #58)

this bug has resurfaced in 84.0.1

gbl954, can you please paste the corresponding message from the error console (accessible from Tools > Developer Tools menu)?

Comment 60

[gbl954]

(In reply to Martin Schröder [:mschroeder] from comment #59)

(In reply to gbl954 from comment #58)

this bug has resurfaced in 84.0.1

gbl954, can you please paste the corresponding message from the error console (accessible from Tools > Developer Tools menu)?

Don't see any calendar specific messages in error console; just reporting that my recurring tasks, with some future ones completed, have again disappeared from today plane, after upgrading to 84.0.1.

Comment 61

[Kadee]

this bug has resurfaced in 84.0.1

For my 78.5.1 (64-bit) [Linux], the behaviour still remains good, ie, no bug return here yet. I didn't even know there was another big series jump pending.