310853 - `All Events` or `All Future Events` filters fail to show any repeated occurrences of recurring events on `Find Events` search pane (Unifinder)

Status: RESOLVED WONTFIX

(Calendar :: Calendar Frontend, defect, P1)

Description

[gekacheka]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051001 Mozilla Sunbird/0.2+

Currently the event list shows recurring events as if they did not recur.
In other words, it only shows the first occurrence.

Sunbird 0.2 showed the current occurrence dates if now is during an occurrence,
or the next occurrence dates if now is before an occurrence, or
the previous occurrence dates if now is after all occurrences.

This behaves predictably when "All Events" or "All Future Events" are shown and
there are events that recur forever.

This bug is to restore this behavior, at least for 0.3a1.  This behavior may
still be desireable for "All Events" and "All Future Events" even if we decide
multiple occurrences should be shown for bounded views (bug 271248).

Reproducible: Always

Steps to Reproduce:
1. create a repeating event that has at least two occurrences in the past
2. view in event list ("All Events")


Actual Results:  
The recurring event is listed with the start date and end date of the first
occurrence.

Expected Results:  
As in Sunbird 0.2:

The event is listed with the current occurrence dates if now is during an
occurrence.
(If I'm late to a meeting, I still want to be able to find the event.)

The event is listed with the next occurrence dates if now is before an occurrence.
(I want to find the meeting I need to attend next.)

The event is listed with the last occurrence dates if now is after the last
occurrence.

Comment 1

[gekacheka]

Attachment: v1 patch: create proxy event with current, next, or previous date for recurring event

(patch -l -p 2 -i file.patch)

For "all" or "future" filters (that return just one item for recurring events),
creates a proxy event with the date of the current occurrence (if now is during
an occurrence), or of next occurrence (if now is before an occurrence), or
previous occurrence (if now is after last occurrence).

Changes:

calendarUtils.js: 
  getCurrentNextOrPreviousRecurrenceDate
    Renamed from getCurrentNextOrPreviousOccurrence.
    Update to use calDateTime.recurrenceInfo.
  getPreviousOccurrenceDate
    Implemented since not part of calIRecurrenceInfo.
    Was part of corresponding libxpical interface, but that doesn't seem to be
in lxr anymore, so I'm not sure if this is better or worse.
    Implementation approach is to get past events in longer and longer ranges
      until one contains occurrences, and return the last occurrence, or 
      until start date is reached.
    Now returns calDateTime instead of jsdate.

mouseoverPreviews.js
  getPreviewForEvent
    Update to use dates directly from proxy event, no need to recalculate.

unifinder.js
  treeView.getCellText
    Use end date directly from proxy event.
  compareEvents
    Use dates directly from proxy event.
    Compare dates using calDateTime.compare
    Remove old millisecond aux functions.

  refreshEventTreeInternal
    If "all" or "future" filter, and event is repeating and started in past,
      create proxy for event, and assign start/end date of current, next, or 
      previous occurrence as described above.

  focusFirstItemIfNoSelection
     use proxy date, don't recalculate current,next,orprevious.

With this patch, listing "all" or "future" events will show the current, next,
or last occurrence rather than the first occurence (and upcoming recurring
meeting occurrences are not lost in the future view).

Comment 2

[Michiel van Leeuwen (email: mvl+moz@)]

I'm sorry, but this patch is way to scary for 0.3a1.
And we should first hava a good spec of the event list. It's currently a mess of
what's displayed mixed with the current time. Either we show the contents of the
view, or limit to current time. But not this weird mix.

Comment 3

[gekacheka]

(In reply to comment #2)
> I'm sorry, but this patch is way to scary for 0.3a1.

My understanding is the goal for 0.3a1 is to implement 0.2 functionality on the
new back end.  This patch restores this for "all" and "future" event filters,
which in current nightlies only display first ocurrence, so users may miss next
occurrence.


> And we should first hava a good spec of the event list. It's currently a mess of
> what's displayed mixed with the current time. Either we show the contents of the
> view, or limit to current time. But not this weird mix.

I agree that the list of filters should be changed, but my understanding was no
UI changes were to happen for 0.3a1, that would wait until after 0.3a1.

I agree the filters should be simplified, perhaps to 
  Events in current view.
  Future events (next occurrence)
  All events (next or last occurrence)
But this should be a separate bug.

Comment 4

[Michiel van Leeuwen (email: mvl+moz@)]

(In reply to comment #3)
> My understanding is the goal for 0.3a1 is to implement 0.2 functionality on the
> new back end.
No, the goal is to have basic functionality with a new backend. I don't think it
is worth the time to mimic exact behaviour in old views (and lists) when they
will be replaced anyway. The views (and lists) should just be basicly usable.
Minor problems are acceptable. (it's an alpha release after all)

Comment 5

[Michiel van Leeuwen (email: mvl+moz@)]

I'm still not sure about this patch. I think the problem is that it makes the list depend on the current time, while the view below it doesn't depend on that. It just sounds inconsistent to me.
I need to spend mor thoughts on the list.

Comment 6

[Matthew (lilmatt) Willis]

Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove

Comment 7

[Matthew (lilmatt) Willis]

Not going to make the 0.3 train.

Comment 8

[Simon Paquet [:sipaq]]

gekacheka,
is this patch still valid or has it bitrotted? If the latter, could you please update it and move it to another reviewer (I'd suggest Daniel Boelzle or lilmatt). If you do so, please also address comment 5 if possible.

Thanks a lot.

Comment 11

[Matthew (lilmatt) Willis]

Not going to make the 0.5 train.

Comment 14

[Søren Munk Skrøder (extended hiatus)]

with regards to bug 396294 which is marked as a dupe of this bug.

This bugs premise is that only the first occurrence of the recurring event is respected with regards to "All future events"/Event filtering.
In my bug report (bug 396294), this is not the experienced behaviour, and therefore I'm unsure that bug 396294 is a dupe of this (although the both concern buggy behaviour wrt. the events listing and filtering)

Experienced behaviour in bug 396294 is that recurring events aren't included for the current month, regardless of whether they are the first occurrence or subsequent recurrences..

So - is bug 396294 still considered a dupe of this bug ?

And perhaps more importantly - is this on the board to be fixed for 0.7 ?

Comment 15

[gekacheka]

Attachment: v2 patch: list current, next, or previous occurence date in unbounded event lists

(patch -l -p 1 -i file.patch)

Updates patch.  Patch depends on patch to bug 278799.

The most important part is in refreshEventTreeInternal where, if the view is unbounded, for each recurring event it replaces the master event (which has the first start date) with the currentNextOrPrevious occurrence.

New: Start dates of recurring events are now prefixed with a '*'.  In the unbounded lists (all or all-future), if any occurrence is in range just one occurrence is shown, but since it is marked with a '*', the user is alerted that there may be more.

Cleanup: patch also clears some old code waiting for this patch to be reimplemented, renames some ids (some describing ms but nativeTime is ns), and removes msNextOrPreviousRecurrenceStart/End functions since occurrence is precomputed (by refreshEventTreeInternal).

Comment 16

[Michael Büttner (no reviews TFN)]

Comment on attachment 295668 [details] [diff] [review]
v2 patch: list current, next, or previous occurence date in unbounded event lists

I personally find it correct to display occurrences based on the current time, but this is definitely something that should get Christian's backing. Requesting UI review before moving forward.

Comment 17

[Christian Jansen]

Generally I support the approach, but instead of displaying a * I recommend to display an icon. e.g and calender with a "this is a repeating event" symbol on combined.

Comment 18

[Christian Jansen]

(In reply to comment #17)
> Generally I support the approach, but instead of displaying a * I recommend to
> display an icon. e.g and calender with a "this is a repeating event" symbol on
> combined.
> 

...I meant on top. ...

Comment 19

[Michael Büttner (no reviews TFN)]

In general, displaying the current occurrences from a series is much better than unconditionally displaying the very first occurrence of the series. This conforms to what I'd expect when looking at events listed for some future range. I'm not interested in when the first occurrence happened, but I always want to know when the next occurrence is. Bottom line, I find this patch buys us a very valuable and welcome feature.

That said, the rule for selecting the current, next or last occurrence is certainly something we need to carefully sort out. With the patch as it currently stands, the occurrence will be selected based on the following rule:

- current occurrence, if now is during an occurence, or
- next occurrence, if now is before an occurrence, or
- last occurrence, if now is after all occurrences

Assume we have a daily recurring event, from 8:00 to 9:00. Looking at the list of today's events after 9:00 shows the occurrence on the *next* day. I'm a bit uncertain if this is really intuitive.

Christian, please decide whether or not we want to feature as it currently stands. Regarding icons and stuff like that, this is outside the scope of this bug and should be handled in a spin-off bug.

Comment 20

[Philipp Kewisch [:Fallen][☁️📆]]

Comment on attachment 295668 [details] [diff] [review]
v2 patch: list current, next, or previous occurence date in unbounded event lists

I changed the unifinder code a lot in my last checkins. While this patch almost applies, I'm not quite sure where to put the last hunk of calendar-unifinder.js (which fails).

Looking alone at the code, r=philipp. I haven't had a chance to test things out though.

Comment 21

[Philipp Kewisch [:Fallen][☁️📆]]

gekachecka, could you provide an updated patch?

Comment 22

[gekacheka]

Attachment: v3 patch: list current, next, or previous occurence date in unbounded event lists

(patch -l -p 1 -i file.patch)

Updated patch.  Function refreshEventTreeInternal now treats 'future' like 'all' to find occurrences, then filters out those with only past occurrences.   Function isItemInFilter now does the same when an item is modified or added.

Comment 23

[Philipp Kewisch [:Fallen][☁️📆]]

This patch increases the load time for the unifinder by about 200 ms on average (10 runs). I tested this using Joey's perf script from bug 415442.

Is there any way to lower the impact? I already introduced a very very large performance decrease beforehand, therefore it would be great to keep the impact as low as possible. You seem to be very proficient with such mathematical things, maybe you have an idea for bug 415442 also?

Also, since this is not blocking, would you be terribly upset if we move this patch to post-0.8 ? We are already past our schedule and I would like to keep the regression risk as low as possible. I'm happy to reconsider if you are sure this patch won't trigger any regressions and you'd like to have it in for 0.8.

On a first glance the code looks fine though.

Comment 24

[Philipp Kewisch [:Fallen][☁️📆]]

Comment on attachment 302484 [details] [diff] [review]
v3 patch: list current, next, or previous occurence date in unbounded event lists

While this patch looks nice from a code standpoint, the performance decrease is still there.

gekachecka, do you have an idea how performance could be improved with this patch? Or do you think the decrease in performance is justified by the functionality of this bug? If the latter, I'll reconsider the review.

Comment 25

[gekacheka]

A problem appears to be the C++/JS boundary is a bottleneck when there are hundreds or thousands of events.  This may be a limitation of the platform (is this why so much of thunderbird is in C++ rather than JS, so it can handle thousands of mail/news messages?).  Are there any improvements expected here with Tamarin (new implementation of JS compiler and runtime)?

It might help if a query to the calendar IDL/C++ could return the CurrentNextOrPrevious events the first time rather than returning one instance and then having to rescan the list to find the next or previous.

It may help in the filtered cases to move filtering code to the C++ side so that the filtered-out events do not have to cross the C++/JS boundary.

I'll leave these for someone else.

Comment 33

[Matthew Mecca [:mmecca]]

Alternatively we could show all past occurrences and the next occurrence with the "All Events" filter similar to what's planned for the Incomplete Tasks filter in Bug 746524. In any case I think we should use calFilter to return the desired occurrence set for the unbound unifinder filters rather than changing the way we display the parent items.

Comment 34

[Philipp Kewisch [:Fallen][☁️📆]]

(In reply to Matthew Mecca [:mmecca] from comment #33)
> Alternatively we could show all past occurrences and the next occurrence
That could be a lot if the event started 200 years ago, i.e Musician's Birthdays.

The All Events filter is already really slow, we shouldn't put in more than needed.

Comment 35

[bernhard krumm]

1.
for 'all future events' 
- repeating events could be listed once, adding the repeat rule

2.
for 'All events' 
- the past of 'All Events' 
 -- may be filtered by adding a 'from-date'
 -- repeating events could be listed once, adding the repeat rule
- the future of 'All Events'  like 1.

Comment 47

[Jean-Philippe MENGUAL]

Hi,

Is there some plan to do a new patch?

Regards

Comment 48

[j.friedrich]

It's been 14 years, it would be great to get a fix for this.

It's really hard to edit reoccuring events per occurence.

Comment 49

[Alex ARNAUD]

(In reply to Jean-Philippe MENGUAL from comment #47)

Hi,

Is there some plan to do a new patch?

Regards

Do you know if there is plan for this one?

Best regards.

Comment 50

[Magnus Melin [:mkmelin]]

No plan for this currently, sorry.

Comment 52

[davelabrecque]

My impression is this behavior won't be changed because of the resources required to generate potentially long lists of recurring events. Is that right?

If so, has anyone considered the option of a user-definable date range to keep recurring event listings limited in length? Or perhaps allowing the full listing, but in bursts of 30 or 50 at a time, each successive burst waiting for the user request it (or not).

If not, why not?

Comment 54

[Chris Graham]

It's really important to me, and I think many others, to be able to find recurring events.

For example, if I'm working with a client I want to know when the next regular invoice date is. Currently there is no good way to do that.

For what it's worth, all other modern Linux calendars handle search far worse than Mozilla Calendar, which adds to the frustration (I just reviewed them all, it's a nightmare). I don't think working recurring event search is a big ask at all, and if nothing else can do this simple thing and Mozilla Calendar can be made to do so, that's an opportunity.

There are many different solutions you could follow...

1. Simply have a "Is recurring" column on the search result view that is sortable. Then at least we can do an "All Events" search and sort by recurring, to see past ours years/decades of irrelevant results. This is very simple but better than nothing.

1b) Even better, have a "Next recurrence" column (blank if not a recurring event). But maybe this is too hard for you to do for the same reason as '2' below.

2. Just show the first future iteration of a recurring event in "All Future Events" searches. Maybe this is what was being tried initially and is slow, but I don't see why it needs to be. For all recurring events that have not had their recurrence span ended, find the first that is in the future. I do this in my own software's calendar's display code - fast forwarding an event based on recurrence settings. I have no idea how your code is working of course, so maybe this is really hard for you folks to do for some reason - perhaps your core event pulling API would need reworking.

3. davelabrecque's suggestion about a user-definable date range is good. Either allow the user to pre-add some time-spans in the configuration, or just have a dialogue where you enter how many future days you want to search ahead for. If you did this I think you could remove "Events in the Next 7/14/31 Days" and "Events in the Calendar Month", because those are rather specific and bloaty IMO.

4. Have recurring events come into "All Future Events" after the non-recurring events. Show a progress indicator at the bottom of the list to show it's still searching, and have the events come in. So what if it takes a few seconds. The existing use-case is still resolved immediately, and we still get the results we want in a reasonable time-frame with no UI lock-up.

5. Add a year view. Then we can use "Events in Current View" to much more effect.

If you could just '1' and '3' it would help a great deal and I don't think would be too hard!

Comment 55

[Jean-Philippe MENGUAL]

Hi,

The most I think about it, the most I think this bug is too hard to fix. Here is a workaround then:

• display the calendra per week/month
• instad of filtering "all future events",, chose "Events in the current view". So you will have the list of events per week, month, multiweeks, according to the view you choosed in View menu. It will display the recurrent events, as well as other, not for the all future, but at least month, week, etc.

Hope it helps

Comment 56

[Dave Labrecque]

Great work-around! Thanks so much Jean-Philippe!

I'd always assumed that recurring events following the initial event in the series simply didn't appear at all via the search function, but it looks like they do appear in all search view modes except two: All Events and All Future Events.

This is a big help. Thank you, again!

Comment 63

[Igor R.]

Is there any hope to have this bug fixed?

This bug, first filed 17 years ago gets duplicates filed every so often. That indicates that people get bit by this issue on a regular basis.
(And how many people decide not file a bug, after finding this one, still unfixed?)

Yes, there is a workaround suggested, but it is just that, - and all users cannot rely on going to Bugzilla, searching for this bug, and finding the workaround buried in a long thread.

Comment 64

[Joel Rocha]

“I don't want hope. Hope is killing me. My dream is to become hopeless. When you're hopeless, you don't care, and when you don't care, that indifference makes you attractive.”
— George Costanza

I've tried to look at the issue, but the problem is so severe it would require a major change that would be too time consuming and error prone to carry out while not being payed to do so. So, believe me: Keep "working around" until a new plugin comes out that perhaps fixes this.

Comment 65

[Dave Labrecque]

Bummer. And what about the user-specified date range approach? Would that not get around the bug?

Comment 66

[Igor R.]

From what I understand, the biggest problem is the boundless time frame. Google Calendar web-interface does not offer open-ended time frames, but it offers a possibility to specify the time frame. Thunderbird limits this to the predefined time frames that are too short (31 days or a month - for "current view", which is inconvenient).

So, let me restate my question:
Can someone from the developer's team look at this issue from the point of view of finding an alternative solution, e.g. setting a customizable period of time for the filter, as suggested in Comment 52 (by davelabrecque) (which would make it similar to Google's), or anything else.
I do not see any response from a developer on the feasibility to that (Comment 52) solution.

Comment 67

[MartinX3]

(In reply to Joel Rocha from comment #64)

I've tried to look at the issue, but the problem is so severe it would require a major change that would be too time consuming and error prone to carry out while not being payed to do so.

https://www.ghacks.net/2021/03/22/thunderbird-financial-report-2020-shows-strong-year-to-year-growth/
"Thunderbird has about $3 million US Dollars in the bank currently; development could proceed for nearly 2 years without any new income coming in."

Not payed? What?

Comment 68

[Joel Rocha]

(In reply to MartinX3 from comment #67)

(In reply to Joel Rocha from comment #64)

I've tried to look at the issue, but the problem is so severe it would require a major change that would be too time consuming and error prone to carry out while not being payed to do so.

https://www.ghacks.net/2021/03/22/thunderbird-financial-report-2020-shows-strong-year-to-year-growth/
"Thunderbird has about $3 million US Dollars in the bank currently; development could proceed for nearly 2 years without any new income coming in."

Not payed? What?

That is nice, however, when i investigated this, i was only a volunteer, not on a full time job.

Comment 69

[MartinX3]

(In reply to Joel Rocha from comment #68)

That is nice, however, when i investigated this, i was only a volunteer, not on a full time job.

Shouldn't volunteers get paid if the project sits on so much money?

Comment 70

[Joel Rocha]

(In reply to MartinX3 from comment #69)

Shouldn't volunteers get paid if the project sits on so much money?

How is this discussion going to help us fix the issue?

I believe in this definition of volunteers: https://dictionary.cambridge.org/pt/dicionario/ingles/volunteer

"a person who does something, especially helping other people, willingly and without being forced or paid to do it"

If you disagree, you better take it with the dictionary developers.

Comment 71

[MartinX3]

(In reply to Joel Rocha from comment #70)

How is this discussion going to help us fix the issue?

I believe in this definition of volunteers: https://dictionary.cambridge.org/pt/dicionario/ingles/volunteer

"a person who does something, especially helping other people, willingly and without being forced or paid to do it"

If you disagree, you better take it with the dictionary developers.

How to fix?
They should pay a developer fixing this problem other people fight with since at least 17 years.

Volunteering for a million dollar company/foundation is modern slavery.

Comment 72

[sukhoi47]

How to fix?

This is the point!
The bug has to enter in the list to be fixed, and I hope that will not take 17 years more.

Comment 74

[Thomas D. (:thomas8)]

Ryan, just came across this from the latest duplicate (of 29 duplicates), bug 1768493.
Only ever finding the first occurence of a recurring event, i.e. not finding recurring instances of an event (and some more flaws when you start deleting from recurrent events) sounds like a pretty painful thing from users pov. Could this be earmarked for a fix in TB 114?

Comment 75

[Lorenz]

coming from the mailing list, I've read through this whole ticket, but still don't understand why all the range limited searches are able to display instances of recurring events, but "all events" and "all future events" are not.

Can some please explain that?

If its only that "all future events" would run into problems with open ended series, then either limiting the search to an managable number of instances or run time (and expanding if needed when the user scrolls to the end of the list) or allowing the user to define a custum range (with the notice that to a big range might lead to an explosion 8-) should solve the problem for most users.

Comment 76

[Ryan Lee Sipes]

Can you take a look at this Andrei?

Comment 77

[Joel Rocha]

(In reply to Lorenz from comment #75)

coming from the mailing list, I've read through this whole ticket, but still don't understand why all the range limited searches are able to display instances of recurring events, but "all events" and "all future events" are not.

Can some please explain that?

If its only that "all future events" would run into problems with open ended series, then either limiting the search to an managable number of instances or run time (and expanding if needed when the user scrolls to the end of the list) or allowing the user to define a custum range (with the notice that to a big range might lead to an explosion 8-) should solve the problem for most users.

So, what you are proposing is basically to remove the "All future events" feature. Like i've said in earlier posts: Keep working around it, because it wont get fixed anyway. The mechanism needs to be re-designed to take recurring and non-recurring events, so that the engine does not enter an infinite loop while trying to show 'All future events', it should instead only show the next occurrence of the recurring event when 'All future events' option is selected.

Comment 78

[Dave Labrecque]

I didn't interpret what he said as eliminating the "All future events" feature.

Surely there's a way for a bright coder to trap for an infinite loop. Lorenz gave two plausible suggestions for how to approach this hurdle. I like 'em both.

FWIW, when I try it, the current functionality doesn't even show the first recurring event when selecting "All future events." Not sure if you were thinking it did, Joel.

As to whether it will ever get fixed: I won't challenge you on your contention. ;)

Comment 79

[Joel Rocha]

Dave: When someone says "All Future events" is the same as "Future events up to a limit" or "Future events with a custom range/limit", something is wrong. Mozilla culture is to be transparent, and i don't see "transparency" coming from those statements.

Comment 80

[Dave Labrecque]

Gotcha. I wasn't thinking of the semantics.

Well, we have a problem, then. Because the current implementation is misleading/buggy as "All Future Events" are not revealed under certain search conditions. In fact no events are revealed under those conditions. So something is wrong even now.

But I think the spirit and meaning of "All Future Events" would remain intact if those (recurring) events were revealed in a finite number of returns at a time. Like my credit card web interface has a button to reveal the following month's transactions. Or a Google search let's you go to the next page if you like.

Certainly some bright coder could make this happen. (FWIW, I'm not him/her. :P)

Comment 82

[Graham Perrin]

(In reply to davelabrecque from comment #52)

… a user-definable date range …

Some overlap with use case 2 in bug 1766799.

Comment 84

[Thomas D. (:thomas8)]

.

Comment 85

[Thomas D. (:thomas8)]

STR:

• Create a repeated event in your calendar which starts on a past day and repeats regularly (e.g. weekly till end of year).
• Ensure that Events and Tasks > Find Events (aka Unifinder or Calendar Quick Filter/Search) is shown.
• Try the following filter ranges from the dropdown list:
  • All Events
  • All Future Events
  • for comparison, e.g. Events in the Next 31 Days

Actual result

• All Events filter shows only the first event in the series (which is in the past per this STR).
• All Future Events shows no events of the series at all.
• By comparison, Events in the Next 31 Days correctly shows all matching recurrences of the event.

Expected

• All Events filter should show all events of the series (well, technically you'd probably want to avoid an infinite loop for perpetual events, and only display a limited range as the user scrolls along)
• All Future Events should show all future events of the series (with the same technical caveat), similar to what Events in the Next 31 Days already does now.

Comment 86

[Thomas D. (:thomas8)]

Sorry.

Comment 89

[mw.bugzilla_mozilla]

As filtering for recurring events in the next 31 days actually works (unlike filtering on all event or on all future events), why can't you just replace '31' by '365' in the source code?

Comment 91

[mw.bugzilla_mozilla]

Can someone answer my post # 89? I would like to grasp why filtering on the next 7, 14 and 31 days works, but isn't available generally?

Comment 92

[Joel Rocha]

Sure, i can answer you: Let's say you have a recurring event that happens each second for the following month. This will lead the code to try to calculate all the 2678400events for the next 31 days. This would be something quite time consuming even for most computers today. Granted, it would return but it is not the best option.

The reason why you say it works is because you probably never scheduled anything for each second of the next month, which is kind of silly, but the idea behind this is that the issue is not in the timeframe you select, but in the option/policy that was choosen that could lead to an infinite or very time consuming loop.

Comment 93

[mw.bugzilla_mozilla]

To Joel Rocha comment 92: Ok - what options/policies are currently allowed to define the recurrence pattern? As a user, it looks like I can have an event recurring, no more frequently than every day, according to a simple pattern (e.g. daily, every 3 days, every weekday etc). So if I kept a list of all initial recurring events which began before today, I can derive another list which only includes initial events which match my search text. Say there are 'N such events. Then for each of them I need to simulate their recurrence dates and for any such dates which fall in the time interval 'now' to 'now + 365', add that event to a list of to be displayed. Finally sort the display list by date, and show it to me.

The work involved in simulating the forward march of recurring events, looks like it grows as the product of 'N' (# matching initial events) x D (number of calendar days from the initial event to now + 365).

This doesn't appear to be too onerous. Am I missing some computational work?

My own personal work-around is to use CalDAV to share my calendar with T'bird and android calendar (the latter has no difficulty with showing recurring events matching a search text).

Comment 94

[Joel Rocha]

When you look at the horizon, it looks pretty flat. Some even think that if the horizon looks flat, then it should mean that the world is flat, and some people still believe that is true to this day.

But some of us, engineers, scientists and astronomers looked deep into it, studied hard, and found out that the world is in fact an imperfect sphere. They announced it to the world, but many, could not believe them.

I suggest you take the same path as the engineers/scientists did. Look at the code, which is open source, and see for yourself if you can sort out this issue. Be a hero, we really need it because this ticket has been open for 18years now.

Good luck.

Comment 95

[sukhoi47]

(In reply to Joel Rocha from comment #94)

When you look at the horizon, it looks pretty flat. Some even think that if the horizon looks flat, then it should mean that the world is flat, and some people still believe that is true to this day.

But some of us, engineers, scientists and astronomers looked deep into it, studied hard, and found out that the world is in fact an imperfect sphere. They announced it to the world, but many, could not believe them.

I suggest you take the same path as the engineers/scientists did. Look at the code, which is open source, and see for yourself if you can sort out this issue. Be a hero, we really need it because this ticket has been open for 18years now.

Good luck.

This is the type of message that does not add anything for the discussion nor to have the issue fixed.

Comment 96

[Joel Rocha]

Some people need to be inspired to do stuff, otherwise they would not be making questions to the community, they would be looking at the code and trying to understand why on earth is this 18years old bug still not fixed. Do i know something more that can help fix this thing? Is there any new/recent technology development that could help to fix it? How can i help fix it?

If i can inspire at least one other dev to look at the code and fix it, i know i did what i could. Help comes in many shapes and forms, we sometimes just think others are being assholes when in fact they are challenging you to be a better man. A man i could not be.

Comment 97

[Mike Hoye [:mhoye]]

Joel, that's quite enough of that; we don't do that here.

Comment 98

[Wayne Mery (:wsmwk)]

mw, thank you for offering to create a solution. Greatly appreciated.

Bug 1763752 has recent WIP code which is likely solution. Eventually it will make progress, but development's current priority is getting the next release ready.

Comment 99

[mw.bugzilla_mozilla]

(In reply to Wayne Mery (:wsmwk) from comment #98)

mw, thank you for offering to create a solution. Greatly appreciated.

Bug 1763752 has recent WIP code which is likely solution. Eventually it will make progress, but development's current priority is getting the next release ready.

Good to know - thanks Wayne.

Comment 100

[Sean Burke [:leftmostcat]]

In testing bug 1763752 as a fix for this one, it's apparent that these infinite intervals would be extremely difficult to implement in a fashion that would match user expectations. Additionally, it's not clear that they provide user benefit that couldn't be provided in a simpler, better way. Bug 1844408 attempts to address some of that user need; if there are use cases that aren't met by that solution, we ask that a separate bug be filed with a feature request.