1738689 - Convert calendar views to html

Status: NEW

(Calendar :: Calendar Frontend, task)

Description

[Henry Wilkes (they/them) [:henry-x]]

With bug 1694820 complete, and bug 1713130 in progress, my next step is to convert the whole #view-box to html. This would include changing the custom elements to html.

I might also change the class hierarchies (e.g. I don't think it makes sense that MozCalendarMonthDayBoxItem and MozCalendarEventBox inherit from MozCalendarEditableItem), and this is probably a good opportunity to do some general code clean up as well.

I'll be keeping an eye on the accessibility tree as well.

Comment 1

[Lasana Murray]

Are you doing a complete xul removal here?

Comment 2

[Henry Wilkes (they/them) [:henry-x]]

(In reply to Lasana Murray from comment #1)

Are you doing a complete xul removal here?

Yes, that is the plan.

Comment 3

[Till Kleisli]

@henry does this also include the Tasks views?

Comment 4

[Henry Wilkes (they/them) [:henry-x]]

(In reply to Till Kleisli from comment #3)

@henry does this also include the Tasks views?

No. Just the day, week, multiweek and month views.

Comment 5

[Henry Wilkes (they/them) [:henry-x]]

Since I'm leaving I won't be able to work on this. In general I was going to replace the custom XUL elements with custom HTML elements instead:

• Some custom elements are already wrapped by a HTML element to give them proper semantics. E.g. "calendar-event-box" is always wrapped by a <li> element https://searchfox.org/comm-central/rev/4ce55228dcb23b3f8d9206080aa46efe4cf0a817/calendar/base/content/calendar-multiday-view.js#450-454 so we should change MozCalendarEventBox to extend HTMLLIElement. Similar for "calendar-editable-item" and "calendar-month-day-box-item".
• Make MozCalendarMonthDayBoxItem and MozCalendarEventBox distinct classes from MozCalendarEditableItem. Currently they inherit from it and it makes the code paths confusing.
• Choose clearer and consistent class and element names.

I was also going to do a general tidy up. Here are some specific things I was planning in this area that do not already have a separate bug:

• Drop or replace the m[A-Za-z]+ properties, like mPixelScrollDelta.
• Instead of using a custom "viewresize" event and onResize https://searchfox.org/comm-central/rev/4ce55228dcb23b3f8d9206080aa46efe4cf0a817/calendar/base/content/calendar-base-view.js#255-259 just attach a ResizeObserver to the view. If we store the previous sizes, we can also fine tune the call to readjustView to take into account if the resize was in the vertical or horizontal direction or both https://searchfox.org/comm-central/rev/4ce55228dcb23b3f8d9206080aa46efe4cf0a817/calendar/base/content/calendar-multiday-view.js#2431
• timeIndicator (https://searchfox.org/comm-central/rev/4ce55228dcb23b3f8d9206080aa46efe4cf0a817/calendar/base/content/calendar-views-utils.js#617) is only used by the multi day views, so should be moved into CalendarMultidayBaseView and be non-global.
• Drop CalendarDnDContainer. It is trying to provide a layer of abstraction to the drag and drop logic but it just makes the code confusing to read and is buggy (bug 1675056), and it is only used for class inheritance by CalendarMonthDayBox and CalendarHeaderContainer. Moreover, the dragging and the dropping should be handled by the views themselves since they will need to handle dragging and dropping between distinct elements. Also, consider bug 1739070
• Related to the above, drop MozCalendarEventColumn. This class basically handles dragging of non-all-day events in the multiweek views, but since dragging can be across multiple days, there is an awkward handing over of a mouse event sequence from one column to the next https://searchfox.org/comm-central/rev/4ce55228dcb23b3f8d9206080aa46efe4cf0a817/calendar/base/content/calendar-multiday-view.js#948-953 which relies on setting a property on the document object! So this seems better suited to be handled by CalendarMultidayBaseView itself which can have a much clearer logic. Once you remove the mouse event logic from MozCalendarEventColumn there's really not that much left, so the rest can be moved into the view class as well.
• Try handling moving an event/task (as opposed to resizing one of its ends, or creating a new event with a mouse drag) as a drag and drop sequence in the multi-day view. Currently we use mouse events for this and then convert it to a drag session when we leave the view https://searchfox.org/comm-central/rev/4ce55228dcb23b3f8d9206080aa46efe4cf0a817/calendar/base/content/calendar-multiday-view.js#894-897. But this does not allow the user to leave and re-enter the view.
• doAddItem and doRemoveItem only accept one event/task at a time, but we always call it as part of a loop https://searchfox.org/comm-central/rev/4ce55228dcb23b3f8d9206080aa46efe4cf0a817/calendar/base/content/calendar-base-view.js#464-474 We should instead pass all the events/tasks in the batch to the views in one method call. This can allow the views to better optimise adding several events, rather than readjusting the DOM with every call.
• Address the inline FIXMEs https://searchfox.org/comm-central/search?q=FIXME&path=calendar*view&case=true&regexp=false