* Have the currently selected dropdown menu item serve as the dropdown's
description in order for screen readers to announce its current
selection.
- JAWS and NVDA both read this as "[element name] [selected value]".
- Chrome screen reader (formerly ChromeVox) does not announce the
description.
* Add a title attribute so the dropdown's element name can be shown by
browsers on hover.
Now that subscriptions and exports are accessed from the same page which
is linked as "Import / export calendars", there is no need to have a
separate "Export calendar" link.
This value was being passed in the template, but the template
had 0 hardcoded instead of injecting the context value. With the other
bug fixes in this issue correctly loading the "All" view properly on
page load, this uncovered that at load time, the course view would not
load overdue items, which also meant a behat test was failing.
The 6 month option was highlighted on load if previously selected,
which was not the case for any other options. This has been removed
so it behaves consistently.
When the timeframe filter was set to "all" when the timeline
block was initially loaded, an incorrect value rendered into
the template meant the timeframe limit was set to 0 (which will
return no results) instead of setting no limit (which would fetch all
action events, as intended).
The following blocks have been removed from the Dashboard:
- Online users
- Upcoming events
- Learning plans
- Recently accessed courses
This change will only apply on new installations.
This commit does few things:
1) Remove unnecessary "I hover over today in the calendar"
steps as it's not necessary to hover onto the day to see the events
any more.
2) Replace "I follow This month" steps to "I follow Full calendar"
3) Update i_create_a_calendar_event_with_form_data() to use the new
fullcalendar lang string.
The legacy M.core.event.BLOCK_CONTENT_UPDATED event has been replaced with a
new core_block/events::blockContentUpdated native DOM event.
The new event can be triggered using the `notifyBlockContentUpdated`
event, and by providing the HTMLElement that was updated, for example:
```
import {notifyBlockContentUpdated} from 'core_block/events';
const someHandler = e => {
// ...
const updatedBlock = e.target.closest('.block');
notifyBlockContentUpdated(updatedBlock);
};
```
The new event can be listened to at any point in the DOM using the
following syntax:
```
import {eventTypes} from 'core_block/events';
const handler = e => {
// The block that was updated.
e.target;
// The id of the updated block.
e.detail.instanceId;
};
document.addEventListener(eventTypes.blockContentUpdated, handler);
```
A backward-compatabibility layer is included to ensure that any legacy
YUI event listener is still called with the same arguments.
This legacy bridges will be removed after Moodle 4.3.
The step "And I wait until ".block_myoverview
[data-control='next']" "css_element" exists" is not correct
because this [data-control='next'] element exists before and
after the step so, in some cases, it might cause the following
step will start earlier than expected.
As pending JS has been added, this wait steps are not required
any more.
