336287 - Multiweek view has inconsistent/faulty navigation (depends on selected row)

Status: RESOLVED FIXED

(Calendar :: Internal Components, defect)

Description

[Stefan Sitter [:ssitter]]

Multiweek view has inconsistent/faulty navigation (depends on selected row)

The navigation in multiweek view is inconsistent. Instead of doing +/- 1/2 week the view does some additional magic with the selected week. As the result you get different results on doing next/previous navigation depending on the selected row.

Steps to Reproduce:
0. Start Sunbird with clean profile. Number of weeks in view is set to
   four (zero previous weeks).

1. Go to multiweek view. The current day (02-May-2006) is selected. 
   View title is 'Weeks 18-22'.

2. Select a day in the last row, e.g. 23-May-2006.

3a. Click on prev. navigation link 'Weeks 17-21' or select View->Previous or
3b. Click on next. navigation link 'Weeks 19-23' or select View->Next

Actual Results:
a. Weeks 20-24 are displayed in multiweek view. 16-May-2006 is selected.
b. Weeks 22-26 are displayed in multiweek view. 30-May-2006 is selected.

Expected Results:
a. Weeks 17-21 are displayed as promised by navigation button.
b. Weeks 19-23 are displayed as promised by navigation button.

Additional Information:
It seems that next/prev does not operate on the current 'base week' of the multiweek view (week 18 in example above) but on the 'selected week' of the multiweek view (week 21 in example above).

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060502 Mozilla Sunbird/0.3a2

Comment 1

[Joey Minta]

Attachment: use startDay

We should be basing the view-move off of startDay, not selectedDay.

Comment 2

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

Comment on attachment 226270 [details] [diff] [review]
use startDay

>+                    var viewElement = document.getAnonymousElementByAttribute(this, "anonid", "view-element");
>+                    savedSelectedDay.day += 7*aNumber;
>+                    savedSelectedDay.normalize();
>+                    viewElement.selectedDay = savedSelectedDay;

This changing of the selected day looks wrong to me. I would expect that moving the view one week would leave the day selected that was selected before the move.

Comment 3

[Joey Minta]

(In reply to comment #2)
> This changing of the selected day looks wrong to me. I would expect that moving
> the view one week would leave the day selected that was selected before the
> move.
For every other view, moving the view moves the selection too, such that the same box/column is selected, even though the date corresponding to that element has changed underneath it.  That's what this does for the multiweek too.

Comment 4

[Simon Paquet [:sipaq]]

Comment on attachment 226270 [details] [diff] [review]
use startDay

Moving first-review to Daniel, since mvl's queue is pretty big and he can only cope with his ui-reviews and 2nd reviews.

Comment 5

[Daniel Boelzle [:dbo]]

Comment on attachment 226270 [details] [diff] [review]
use startDay

I think moving the selection too is correct.

r1=dbo

Comment 6

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

(In reply to comment #3)
> For every other view, moving the view moves the selection too, such that the
> same box/column is selected, even though the date corresponding to that element
> has changed underneath it.  That's what this does for the multiweek too.

For other views, the previously selected day is (usually) not visible anymore after switching the day. For multiweek view, it does stay visible. So you can't compare them that easy.

Comment 7

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

Comment on attachment 226270 [details] [diff] [review]
use startDay

I'm still not convinced that this is the right way, but at least it is better then current behaviour.
r2=mvl

Comment 8

[Joey Minta]

Patch checked in.  Feel free to file additional bugs if there's a better way to make this navigation work.  (zoom-scroll?)