Before this change the messages in the message popup would be loaded
onto a page in a random order, based on the speed at which the user's
browser was able to render each template.
This causes the messages to be attached to the page sequentially, after
they have all been rendered asynchronously.
The url, which was used for guessing the image, was queried with the
key 'discoveryurl', which is not defined in the context of an issuer.
The baseurl should be sufficient to retrieve the favicon.ico from a
server. That's why the key for was changed from 'discoveryurl' to
'baseurl'.
While participants page is being refactored, there are links (fullname)
going and changing, leading to inestability in tests that were using
those links.
When possible, provide an alternative, stable path, in this case, the
tags page itself can be used to jump to the user profile, keeping the
tag tests better isolated.
There use to be a little cot to easily navigate from the
participations page to the enrollments page.
In boost it was already hidden, but present and the test was still
working (non-javascript).
With the conversion, the functionality is 100% gone so, right now,
the only way to navigate from participats to enrollments (that will
dissappear with with unification), is using the course admin cog.
It turned out that behat's "I should see ..." does not work for buttons
rendered as `<input>` elements so this assertion worked only in Boost
where the button is rendered as `<button>` but not in Clean.
But we do not really need this check here. All we need is to make sure
that the form has been saved successfully. For which, checking for the
text on the page is enough.
p.s. Another mistake of mine to not double-check behat on both standard
themes. Sigh ...
This Behat scenario was not failing only because it actually relied on
the bug in the wrongly set accepted_types for submission attachments.
Now that the previous commit has fixed that bug, this scenario started
to fail correctly.
We need to do the same trick here as we are doing in the latter
scenario: we first upload a valid file to bypass the upload repository
checks, and rename it before submitting the form. That allows us to see
that the invalid file is caught finally.
p.s. It was a silly mistake of mine. I should had been wondering why
the same procedure worked for one field and not for the other. I would
spot the bug with wrong accepted_types earlier.
