318317 - Revise selected day change when scrolling through the (multiweek) views.

Status: NEW

(Calendar :: Calendar Frontend, defect)

Description

[Thomas Hedden]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050910 SeaMonkey/1.0a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050910 SeaMonkey/1.0a

In Month View, if you select a date (day of the month), either by clicking on it or by clicking on the "Go to Today" button, and then change month, the day of the new month which has the same date/number as that of the previously viewed month is "selected", that is, it is displayed in a light blue color. For example, today is November 30th. In Month View, I click on the "Go to Today" button, and then change to December. In December, the 30th of DECEMBER is displayed highlighted in light blue. (Note that the other form of selection indicated by a thick frame around the date stays on NOVEMBER 30th.) IMHO this is improper behavior. I think that if the actual day that was previously selected (in this case, November 30th) is still viewable within the month that is currently being viewed (since Month View of December shows the last few days of November), then that actual day should still be selected, as is done by the form of selection with the thick frame. If the actual day that was previously selected is no longer visible in the month that is currently being viewed, then either NO day should be selected (until and unless you actually click on a new day), or, if you want to get fancy, the calendar could keep track of what day of the month was selected the last time that month was viewed.

Reproducible: Always

Steps to Reproduce:
1. Change to Month View and select a day, either by clicking on a day or by pressing the "Go to Today" button. Remember the date/number of this day.
2. Change the month by clicking on one of the month names to the right and left of the name of the month that is currently being viewed (at the top of the Month View client area).
3. Look at what day (date/number) is selected (displayed highlighted in light blue) in the new month.

Actual Results:  
The day (date/number) that is selected (displayed highlighted in light blue) in the new month is the same as that in the month that was previously being viewed.

Expected Results:  
I think that if the actual day that was previously selected (displayed highlighted in light blue) is still viewable within the month that is currently being viewed, then that actual day should still be selected (as is true for the form of selection with the thick frame). If the actual day that was previously selected is no longer visible in the month that is currently being viewed, then either NO day should be selected (until and unless you actually click on a new day), or, if you want to get fancy, the calendar could keep track of what day of the month was selected the last time that month was viewed.

Comment 1

[Joey Minta]

The thick border represents 'Today', and never changes.  The currently selected day (which will be used as the default for creating new events), I feel, should change.  Having a 'hidden' selected day that isn't visible (the 'fancy' solution suggested') would be extremely confusing to users, since the program is using data that the user has no access to.  Alternatively, having no selected day leaves the program at a loss for what day the new event dialog ought to default to.

What is the advantage of having no selected day?  What's the use-case for not changing it?  I really can't understand why this would be desired behavior.

Comment 2

[Thomas Hedden]

My point is that the date/number in a DIFFERENT month is no longer the same date as what the user selected. A date is a number of the day in a particular month in a particular year. If the month changes, then the number alone no longer has any meaning in the new month that is being viewed. Since it has no meaning in the new context, I feel it should be hidden.

> Having a 'hidden' selected day that isn't visible ...
> ... would be extremely confusing to users, since the
> program is using data that the user has no access to.
I don't find this confusing at all. What I find confusing
is to have a date selected which has only the day number
of the selected date, but a different month from the
selected date. The user can change it at any time by
clicking on a day.

> Alternatively, having no selected day leaves the
> program at a loss for what day the new event dialog
> ought to default to.
I don't see why the program should have a default date
at all in a month that the user hasn't selected a day
in, unless it's today or unless perhaps the user had
selected a day in that month in a previous viewing
of that month.

> What is the advantage of having no selected day?
My point is not that there is an advantage in having
no selected day, merely that having a selected day
which has no meaning in the new month is confusing.

Comment 3

[Joey Minta]

*** Bug 324273 has been marked as a duplicate of this bug. ***

Comment 4

[Nuno Gonçalo Brito]

I have inserted issue bug 324273 which is a duplicate of this (sorry!).
For me, "Week View", "Multiweek" or "Month View" are exactly that: views. I do not expect that scrolling a view will be changing the day that I have just selected.
Please don't move the selection when you scroll the views.

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

I'm not sure how I feel about the no-selection versus same-day selection. 

However, this:

> I think that if the actual day that was previously selected (in this case,
> November 30th) is still viewable within the month that
> is currently being viewed (since Month View of December shows the last few
> days of November), then that actual day should still be selected,

does seem like the right thing to me.

Comment 6

[Nuno Gonçalo Brito]

For me selecting a day is like putting a marker on it and the thing should work like this:
You have selected a certain day because you are planing to create/edit an event on it. But then you want to navigate a little and see what's in the next week or month or what day of the week a particular day (which is not visible in the current view) is, or anything else that you might want to check out. What do you do? You scroll the view until you find what you want.
Now that you have found what you wanted to see, you want to return to the day that you had previously selected and that you were planing to change. What do you do? You just scroll back until you see the "selection mark" (i.e. the shadowed square of the day) come into view.
It's simple, there is no need to take note of what day you had selected, if you need to edit any other day you will most surely need to click it anyway, so I don't see where is the confusion is. What is confusing is the current behaviour in which you have a selection which jumps arround completely out of your control  with no visible advantage.
This is my opinion and that of the people with whom I discussed this.
Of course, in "day view" if you scroll the view you change the selection, i.e. the selected day is the one that you are viewing and when changing to wider views that is the day that should appear as selected.

Comment 7

[Stefan Sitter [:ssitter]]

I prefer the current behavior. So it is always visible to me which day is selected. If I remember correctly Evolution and Outlook handle it the same way. (This doesn't mean Sunbird has to do it the same way but it shows what other programs do.)

Comment 8

[Matthew (lilmatt) Willis]

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

Bugspam filter: TorontoMostafaMove

Comment 9

[cmtalbert]

(In reply to comment #7)
> I prefer the current behavior. So it is always visible to me which day is
> selected. If I remember correctly Evolution and Outlook handle it the same way.
> (This doesn't mean Sunbird has to do it the same way but it shows what other
> programs do.)
> 

I also prefer the current behavior. Because we use that selected date to pre-fill the new event/new task dialog, it is important to visually indicate what the current selection is. Reporter, please attempt this with the latest nightly and see what you think.  When moving from month to month, the day number selected remains selected, but it does so in a bit cleaner fashion than it did when you first encountered this issue.

Comment 10

[Ray Kiddy]

The current behavior seems odd. For example, today is August 28. I am looking at the Month view. I can hit the arrow to advance to September.

There are two odd things about this.

First, the "selected" date is now September 28.

Second, the "selected" date is now September 28, even though the current date, August 28, is still visible on the first row. What is the justification for this?

Also, can a bug be UNCO at the same time it is used to close a duplicate? Should this not become confirmed?

Comment 11

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

Setting uiwanted to draw attention. We should clarify how the selected day should change. Ray, thanks for your comment, it helped me understand the issue here without reading much (lazy me ;-)