Clicking on the (cal) popup after changing a date input field
still uses the original date and not the new date in the input
field.

Probably need something to pull the current date from the input field
and pass that to the back end as part of the cal activation.

Found while fixing issue2550932.

On Sun, Feb 26, 2017 at 03:25:52AM +0000, John Rouillard wrote:
> 
> Clicking on the (cal) popup after changing a date input field
> still uses the original date and not the new date in the input
> field.
> 
> Probably need something to pull the current date from the input field
> and pass that to the back end as part of the cal activation.
> 
> Found while fixing issue2550932.

Does that only occur on a *failed* submission (where an error occurs) or
generally? A successful submit should redirect to the new item so I fail
to see how this could keep the old value.

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: office@runtux.com

I have seen this, too.
It does not need submit, it happens while editing an issue.

To reproduce:
- open an issue with a date set to 2016-03-31 (oops, long overdue)
- to get in the correct range, change the 6 to 7: 2017-03-31, but do NOT
submit yet
- now click on (cal) to get the popup to adjust it to a suitable date
Result: The calendar popup shows March 2016
Expected: The calendar popup shows March 2017

Or if you clear the date, February 2017 should show, but it still shows
March 2016.
When fixing this: Beware about invalid dates, as there was no error
checking at this point.

In message <20170227091841.GA10056@runtux.com>,
Ralf Schlatterbeck writes:
>
>Ralf Schlatterbeck added the comment:
>
>On Sun, Feb 26, 2017 at 03:25:52AM +0000, John Rouillard wrote:
>> 
>> Clicking on the (cal) popup after changing a date input field
>> still uses the original date and not the new date in the input
>> field.
>Does that only occur on a *failed* submission (where an error occurs) or
>generally? A successful submit should redirect to the new item so I fail
>to see how this could keep the old value.

The value is always the value of the last submit either from the
database or the form at time of submit.

The case I am talking about is:

   view a page with a date. Lets say its 2017-02-19.

   type in a new date e.g. 2017-03-10

   click on (cal)

   the highlighted date is 2017-02-19 not 2017-03-10

I claim it should highlight 2017-03-10, the date displayed in the
input box.

Does that clarify?

				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

In message
<1488196866.65.0.830643908552.issue2550935@psf.upfronthosting.co.za> ,
Thomas Arendsen Hein writes:

>I have seen this, too.
>It does not need submit, it happens while editing an issue.
>
[elided correct direcions to reproduce]
>When fixing this: Beware about invalid dates, as there was no error
>checking at this point.

The lack of error handling was the cause of issue2550932.

The fix was to catch the exception if the date passed to roundup to
display the calendar was invalid. This stops the traceback. In that
case the calendar highlights today.

Since using the current date selector requires javascript, I have been
wondering if a pure javascript date selector may be useful. It should
be faster. Also many browsers have built in date selectors if the
input type is set properly (maybe to date??).

I am not sure if we should go one of those routes. In the input
type=date case, it will fall back to a text input box. Without
javascript enabled the (cal) link should not be displayed (but it is
which seems to be a bug in our classic ... templates).