…nnector

…f window instead of canvas scroll

…, ignoring the value assigned

…ated with aui-datatable-edit

…and empty option-value

…n-Align-Sugestion

…event-submit-change

…rollable

…Date from the DatePicker

This bug was happening because when the user clicks on the test field the datepicker code shows the calendar again and sets its dates to the ones in the field's value. Since the text field doesn't have the time information of the selected date (the default mask has only the day, month and year), the date object created from it would have a different time than the original (in the default case it would be the same as the time on the user's computer), though it would still be the same date. The calendar module considers all of its dates as having the time set to 12:00:00, so if the selected date had been equal to the minimimDate option, it would reject it when the user clicked the text field before 12:00:00 (similarly, it would reject dates equal to the maximumDate when the user clicked after 12:00:00).
So what I did was fix the dates being passed to the calendar's selectDates function, adjusting the timestamp to make sure that it won't be rejected when the date is equal to minimumDate or maximumDate.

Cloned fields were only receiving the field properties of the original field during creation. Attributes like hiddenAttributes weren't being passed, so this configuration wouldn't be respected for cloned fields.
While fixing this for hiddenAttribute I noticed that this was already happening for all other non-property attributes. I checked these other attributes one by one and this fix is now making sure that the ones that need to be passed over to the cloned field are doing so.

This reverts commit fe259c3.

This reverts commit 30ec805.

This reverts commit 3db60bc.

This reverts commit ccf41b1.

The first version of a simple Undo/Redo module.
To use it, the user should call the 'add' function whenever a new action that should support undo/redo funcionality happens. To be used by the UndoRedo module, actions just need to be objects with the 'undo' and 'redo' functions properly defined. Afterwards, the user can call UndoRedo's 'undo' and 'redo' functions, and the module will take care of undoing/redoing the right action.

When the async functionality is added we'll have a different concept for 'actions', so renaming the current 'action' objects to be 'states' instead.

Y.UndoRedoTestUtils has a few utility functions to help write unit tests for the Undo/Redo module.

This is extening the UndoRedo module to allow for async undo/redo actions. This is done by checking if these actions return promises, and making sure that any subsequent actions will wait for pending async actions before running.
Since we now have a different concept for 'actions', I've renamed the objects sent to the 'add' function by the user to 'states' instead.

These utilities were added to Undo/Redo:
(1) Clear history
(2) Can undo / can redo
(3) Undo peek / redo peek

The user can now specify a maximum undo depth, for memory saving purposes.