The conditions for updating the progress in the progress bar were
mistakenly removed. We need to revert these to ensure proper operation
of the progress bar.
- Use $DB->count_records_select() and $DB->get_recordset_select()
instead of using full SQL queries.
- Other fixes:
- Remove unused variable in progress_bar::update_raw()
- poll_stored_progress tidy-ups:
- Use validated parameter.
- Add return types for the external methods.
- Alters existing progress_bar class to support extension
- Adds stored_progress_bar class as child of progress_bar
- Adds webservice to poll stored progress
- Updates database tables
- Bumps version
- Adds unit/behat tests
The only backpack implementing OBv1.0 was Mozilla Backpack. It closed
in 2019 and their badges were moved to https://backpack.openbadges.org/
by Badgr.
However, as Badgr is supporting OBv2.0 too, it makes no sense keep OBv1.0
implementation in Moodle: it has caused some issues and over-complicates
current code.
* Move the shared drag fixture out of the Atto plugin;
* Switch to using faster generators for populating private files;
* Clarify required fields for private files generator
It seems that the loading of the h5p content upsets other interactions
with the page in Firefox as it loads. Unfortunately I haven't found a
reliable way to handle this with pendingJS yet.
This is the poor man's fix and we should find a better solution.
If there's a driver error, for example from a step taking too long, then
this kills the entire Behat run and we have to start from scratch.
This change instead throws away the original connection and starts a new
one to try and continue the test.
W3C WebDriver Element::Click, Element::Clear, and Element::SendKeys all
state that the WebDriver implementation (chromedriver, geckodriver,
edgedriver) should scroll the element into view if it is not already
visible.
It is wrong for us to check if the element is visible or not before
calling these as it may not be but will during the click/clear/type
event.
This upstream bug prevents creation of an anchor with a hyperlink where
the content has a block-like display.
The workaround is to wrap the content in a span, set the display to
inline, call the `createLink` command on the span, move the content out
of the span, and then remove it.
This is only done for Firefox-based browsers.
This upstream bug prevents creation of an anchor with a hyperlink where
the content has a block-like display.
The workaround is to wrap the content in a span, set the display to
inline, call the `createLink` command on the span, move the content out
of the span, and then remove it.
This is only done for Firefox-based browsers.
