1745229 - Add calendar view tests

Status: NEW

(Calendar :: Calendar Frontend, task)

Description

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

This is just a list of calendar view features we don't have tests for.

This is mostly focussed on the multiday view because I'm working on bug 1713130 right now, and it has lots of features. Once I move onto bug 1738689 there's a chance we'll have more to add for the multiweek views.

As a general point, in the multiweek views, we don't run many tests in the rotated view. The exception is the tests in recurrence/browser_rotated.ini. In addition, we're missing tests for right-to-left displays. Rotation and right-to-left become particularly relevant for:

• Positioning non-allday events.
• Positioning of the "now" time indicator.
• Dragging to create, resize or move events.
• Scrolling the view.

Some existing tests where we can add rotation and right-to-left tests are timezones/browser_timezones.js (tests positioning) and browser_dragEventItem.js (test dragging) and views/browser_viewSwitch.js (mostly tests the scroll position and number of visible hours, despite the name).

Here are some specific features we don't have tests for (I'll update this with future edits as we work through them or find more):

• Dragging to create, resize or move events using the magic/auto-scroll feature (holding the mouse at the edge). Probably can be added to browser_dragEventItem.js. Note: bug 1739364 added this auto-scroll in both directions.
• The position of the drag "shadows" during a drag event.
• The snapping of drag positions to 15 minute intervals when not holding "Shift". browser_dragEventItem.js currently runs the tests with Shift held.
• Creating an event by double clicking in the middle of an hour box. Currently, we only test clicking at the start (https://searchfox.org/comm-central/rev/33006a9547416e7bb3de9f15f769979330052449/calendar/test/CalendarTestUtils.jsm#809) which initialises the event to start at that hour, but we can also create events at 15 minute intervals https://searchfox.org/comm-central/rev/33006a9547416e7bb3de9f15f769979330052449/calendar/base/content/calendar-multiday-view.js#92
• Creating an event with the context menu, which also uses the clicked position https://searchfox.org/comm-central/rev/33006a9547416e7bb3de9f15f769979330052449/calendar/base/content/calendar-multiday-view.js#120 See bug 1741191.
• Clicking a day's all-day header, or event column (not on an item) to "select" the day. I think this just highlights it. (Maybe this behaviour should be extended to also clicking the "Mon 1 Jan" heading.)
• A wheel event will only scroll the view in the "time"-direction if it is above the timebar or an event-column. Scrolling in the non-time-direction works as normal. Specifically, scrolling above the blank corner, the day heading or the all-day header will not shift the first visible time. However, if the all-day header has its own overflow, scrolling should still work on it. I.e. test this method https://searchfox.org/comm-central/rev/33006a9547416e7bb3de9f15f769979330052449/calendar/base/content/calendar-multiday-view.js#2127
• The first visible hour remains the same when resizing the view, or when an all-day header has an event added or removed, which resizes the headers.
• Rotating the view re-positions the "now" time indicator and the events. It also preserves properties, like the first visible minute.
• Setting the "calendar.view.daystarthour", "calendar.view.dayendhour" and "calendar.view.visiblehours" preferences changes the view.
• The position of the "now" time indicator, and it being updated.
• Selecting events in the event tree changes to the same week and centers them in the view. I.e. test https://searchfox.org/comm-central/rev/33006a9547416e7bb3de9f15f769979330052449/calendar/base/content/calendar-multiday-view.js#2914
• Changing the number of visible hours using "Ctrl +" or "Ctrl -" https://searchfox.org/comm-central/rev/33006a9547416e7bb3de9f15f769979330052449/calendar/base/content/calendar-multiday-view.js#2996 See bug 1745227
• Trying to edit non-editable events. E.g. testing dragging, clicking event name to rename, and context menus. browser_propertyChanges.js has events that are meant to be non-editable, but it doesn't test this in practice.
• Test positioning of tasks with or without an entryDate and/or dueDate. As in browser_timezones.js.
• Test for an all-day recurring event with an exception. We have browser_weeklyWithException.js for a non-all-day recurring event with an exception. browser_annual.js tests an all-day recurring event, but it doesn't have an exception.
• Tests to cover the invitation display, as well as the visibility state of the link in the status bar. See bug 1754084

Comment 1

[Lasana Murray]

I have not looked at this in a while but I think we should get rid of the custom drag and drop implementation if possible. If we decide to do this, I think some of those drag tests will have to be updated.

Comment 2

[Alessandro Castellani [:aleca]]

I have not looked at this in a while but I think we should get rid of the custom drag and drop implementation if possible

Can you elaborate on why we should remove it?

We should add to this list all tests to cover the invitation display, as well as the visibility state of the link in the status bar, recently fixed in bu 1754084

Comment 3

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

(In reply to Lasana Murray from comment #1)

I have not looked at this in a while but I think we should get rid of the custom drag and drop implementation if possible.

Are you referring to:

1. dragging in the day columns in the multiday views (when dragType == "move"), or
2. dragging between the all-day headers and dragging between the monthday boxes, or
3. something else?

Comment 4

[Lasana Murray]

This:
https://searchfox.org/comm-central/rev/7b67182867d378db583e9b3f75313021e9045eac/calendar/base/content/calendar-multiday-view.js#203

It was a pain to test and difficult to follow when they broke. Not a priority but if possible they should use the drag and drop api instead of polling mousemoves. Likely not a trivial task though.

Comment 5

[Lasana Murray]

(In reply to Alessandro Castellani [:aleca] from comment #2)

We should add to this list all tests to cover the invitation display, as well as the visibility state of the link in the status bar, recently fixed in bu 1754084

Those won't fall under the calendar views. "Calendar views" is the tabular area that displays events on the calendar tab. The current invitation display has some tests already (I think) and more can be added when the enhancements are done. Let's hold off on too many tests for the link for now in case there are more changes to be made.

Comment 6

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

(In reply to Lasana Murray from comment #4)

This:
https://searchfox.org/comm-central/rev/7b67182867d378db583e9b3f75313021e9045eac/calendar/base/content/calendar-multiday-view.js#203

It was a pain to test and difficult to follow when they broke. Not a priority but if possible they should use the drag and drop api instead of polling mousemoves. Likely not a trivial task though.

We still need most of that mousedown/mousemove/mouseup code for dragging the starting and ending times, and for dragging to create an event. The "dragging" in this case is only a drag gesture, like drawing, and there is no transfer of data to be considered drag-and-drop. I already updated the corresponding test in this revision https://hg.mozilla.org/comm-central/rev/938a93cbea7d to use synthesizeMouseAtPoint. It is still a bit hacky, but it is better than it was.

Dragging to move an event, however, could use the drag-and-drop events so we can drag an event in or out of the multiday views (currently it is only one way https://searchfox.org/comm-central/rev/7b67182867d378db583e9b3f75313021e9045eac/calendar/base/content/calendar-multiday-view.js#903-923).

Note: all this will probably get moved around in bug 1738689 so I was going to wait until after that to properly consider drag-and-drop in the calendar.