When a YUI dialogue was opened, it was focusing on the boundingBox, with
the browser moving the scroll position to focus on the top of the
boundingBox. This caused a jump. This only happens when the dialogue is
modal and consequentially has a maskNode present as it changes the initial
positioning behaviour of the boundingBox.
To avoid this, when the maskNode is shown, the dialogue is position at 0,0
in the current viewport. For centered dialogues, the dialogue is
automatically re-positioned after the window has shown. For non-centered
dialogues, the original position is stored and the dialogue is restored to
that position after it has been displayed.
This should not interfere with use of the align function as this will be
called later in the proceedings, after the show has run.
This fix is mostly based on what Colin Chambers found out. This commit
is a simplification of his work.
The problem is that the Chrome / Selenium 2 integration cannot swich to
a window with a blank name. The work-around applied here is, when we
switch away from an unnamed window, we set a name on it. Then we can use
that name to switch back.
Unit tests were failing on MSSQL. gc_collect_cycles() was
removed from the phpunit utils.php file to save time in running
the tests, but MSSQL doesn't clean up open files as well as
other databases.
This patch includes the garbage collection for the unit tests
that require it.
This setting is not compatible with combinations of aggregation methods
and the ways in which it does and does not work are not documented. It
was voted to remove it completely by the gradebook workshop, so I have
completely removed it and added a warning for all affected courses + restored
backups.
We now user $CFG->navcourselimit to limit the number of
courses shown in the navigation when browsing another users
full profile. Previously it showed all courses which caused
some slowdown.
When resetting a sequence number, we call change_database_structure()
which in turns clears the MUC cache for databasemeta. This cache contains
information about the table, columns, etc.
After the cache is cleared, it must be re-filled, and it was discovered
that the get_columns() code which fills this cache can take a particularly
long time. Given that this is called for every table in Moodle, this can
add up to a significant period, and this is done on a per-testsuite basis.
On my SSD install this was taking approximately 40 seconds on each re-fill
of the cache.