This can happen when the 'dragover' event fires as has been observed
in Safari. When the dataTransfer.types property of the event is null,
accessing types.length throws a JavaScript error.
There are numerous bugs with this new module to do with showing the currently selected date,
random changes in the selected dates, showing multiple selected dates and css errors.
This reverts commit 1d128663f69be8b60fc28b6b7732acd24d800a98.
This reverts commit 4a521e6596918279fd0cdeb47d06e7906bc004cc.
The aria-live="polite" attribute is incorrectly added to the fieldset,
causing the entire fieldset to be read out on change in some browsers. This
is unnecessary.
It also does not announce the current state of the fieldset (collaped or
open) and should.
The calendar popup toggle must use an image, rather than an input with type
of image as the latter is actually a form of submit button, and hence it
steals the focus away from the real submit button.
The usergetdate function is not only used to display dates, it is also passed
to the function make_timestamp. This means users using another calendar type
other than Gregorian will generate incorrect timestamps which may be saved in
the DB or used to populate the date_selector and date_time_selector elements.
For example, when creating an assignment using another calendar type other
than Gregorian, the mod_form.php file calls $this->apply_admin_defaults()
which uses the function usergetmidnight to set the "Allow submissions from"
date to today's date and the "Due date" field to 7 days in the future. The
usergetmidnight function calls usergetdate which is then passed to
make_timestamp. Since the usergetdate function was using the calendar
type's timestamp_to_date_array function the date being passed to
make_timestamp was not in Gregorian. So, when using the hijri calendar the
year 1434 was being passed which was generating a large negative number as
the timestamp which was then used to populate the date fields.
1) Moved the calendar types location to a sub-folder in the calendar directory.
2) Removed/moved language strings.
3) Removed calendar types that should be downloaded as plugins.
4) Removed a Non-English language pack for the Gregorian calendar type that
should be downloaded separately.
5) Removed custom files responsible for checking for updates and uninstalling
calendar types, which should be done by core.
6) Removed JS from the calendar_month block as there is no non-JS alternative
provided and the JS written does not make use of the YUI library to ensure
multiple browser support.
7) Removed code from the base class responsible for creating timestamps that
are saved in the DB.
8) Added PHPDocs.
Note: In the original patch we are editing core functions responsible for saving
time in the database in the calendar base class. This is very dangerous, we do
not want to touch these functions as it could cause a complete fubar of the
database. There are places we are forcing the use of the gregorian calendar as
we are passing dates generated by the PHP date function, where as sometimes
we pass dates from usergetdate (which was being overwritten to return the
date specific to the calendar). We can not expect third party modules to
change the calendar type depending on the format they pass to these functions.
Fixes display issues with the filepicker dialogs that were
converted to M.core.dialogue.
Note: These dialogue use table based layouts and the table width is not
counted in the form that it sits in. I have changed the dialogues to have
a wider width but for really small screens this causes horizontal scrolling.
The only solution for that is to rewrite all the filepicker/filemanager dialogs
to use css for layout.
