Make XBlock client-side runtimes proper classes, so that handlerUrl can
be defined in a per-runtime way, and we can have multiple runtimes on a
single page.
[LMS-1630][LMS-1421][LMS-1517]
Users will first be shown the first 25 responses of a viewed thread and
then have the option of loading 100 more at a time until all responses
have been loaded. This mitigates the performance impact of very large
threads by avoiding the need to render and transfer over the network
all content of a large thread at once. It will also allow students with
slower browsers to interact with large threads even if they cannot load
all of the responses.
Previously, buttons were activated on pressing Enter, but the expected
behavior is to activate on pressing Space. Several JavaScript errors
that prevented various buttons from properly activating via the keyboard
are also fixed.
This change involves substantial refactoring of the relevant code to
reduce duplication. It also makes the templates for the vote buttons
more consistent and cleaner.
JIRA: FOR-64
This button has been broken for at least a year, so the code has
suffered from bit rot and should be reimplmemented if the feature is
necessary in the short term (which is unlikely since it has been broken
for so long).
The show/hide toggle now properly acts like a button, and focus is now
trapped on the loading element for both the show/hide action and loading
of a new page.
Now the interface will reset apropriately and allow a user to retry
expanding the discussion or loading a new page, and the alert message
will ask the user to retry.
JIRA: FOR-300, FOR-301
For accessibility purposes, it is bad to allow a user to initiate
loading of additional threads in the navigation sidebar and then shift
focus away from the sidebar, only to have focus snap back when the
additional threads are loaded. Now, we trap focus on the loading element
as recommended by our accessibility consultant.
JIRA: FOR-238
When a user attempts to load more threads in the forum navigation
sidebar, reset the state of the world so the user can retry, and alert
the user appropriately.
AJAX requests on forums pages occasionally fail (usually when a request
to the comments service times out), but the user is not made aware of
the failure. This manifests as either the system not appearing to store
state (e.g. if an attempt to flag a post fails) or something taking
forever to load. Now, a modal will pop up to alert the user that a
request has failed and instruct them to reload the page.
In the longer term, we should fix each user gesture that results in an
AJAX call to gracefully handle a failure by resetting the state of the
world appropriately and aleritng the user.
JIRA: FOR-37
The motivation for this change is performance. The forums UI code gets
the list of users for each role and renders the staff label based on
those lists. The list for the staff role is expensive to compute because
there is no index on the is_staff attribute, and we cannot create one
because the User model is built into django.
Users with is_staff=True are still assigned the Moderator role upon
enrolling in a course, so this change will have no practical effect
except that a user who is granted staff privileges after enrolling in a
course will have to be made a Moderator in order for their posts to be
labeled.
Additionally, the UI did not use the list of users with the Student
role, so that list has been removed as well.
They now include screen reader-friendly text, have the ARIA checkbox
role, activate on keypress (for space or enter), and occur in the DOM
after the header information (title, etc.)
The "Report Misuse" div is now focusable, responds to keyboard input,
and has appropriate attributes to indicate that it is a toggle button.
This fixes FOR-201 and FOR-209.
Now, when the list is reset (e.g. by sorting), the first thread is
focused. When the "Load more" link is clicked, upon loading more
threads, focus moves to the thread immediately following the thread
that was previously last in the list.
Previously, when the window was scrolled down past the top of the
discussion content pane, scrolling right would cause the sidebar to
appear above the background of the content pane but below the text.
This is only an issue with very small windows or with the text size
increased significantly, which is why this came up in an accessibility
audit. Now the sidebar is fixed to the left side of the page instead
of the left side of the viewport.
