The sensitive text feature was implemented with <label> and hidden
checkbox <input> elements. There were two issues with this
implementation:
1. The user couldn't navigate to the "show/hide more" button using
keyboard.
2. The label indicates two actions at the same time ("show/hide more"),
making it unclear what the function of the checkbox was and what the
current show/collapse state was.
As it is generally preferrable to use built-in HTML elements for the
best semantic, this commit moves to use the <details> and <summary>
elements for the sensitive text feature. The browser will open/collapse
the content in <details> automatically when the user clicks on the
<summary>, and keyboard navigation support is built-in.
This commit also changes the button to display "show more" or "show
less" depending on the state for visual clarity. This button is hidden
from the accessibility tree using `aria-label="false"`, as the <details>
element already exposes its state to the tree and we want to avoid
duplicated information.
A few caveats:
* The "show/hide sensitive content" button for sensitive attachments
hasn't been changed yet as I'd like to get more feedback about the new
implementation.
* As the summary/content warning text itself is also part of the
<summary> tag, the user can now also click on them to toggle the
visibility of the sensitive text. This may not be desirable as the
current interface does not make it clear that this could happen; the
user may try to select some text from the summary and be surprised
by the sensitive text being expanded. One way to improve this would
be to add an event listener to the summary text and call
`preventDefault`, but this would introduce JavaScript code.
Otherwise, emojis containing forbidden symbols (for example, `-`)
appear in "emoji selector" on admin/new page, but are not replaced
with emoji image on submit.
Also add a note to documentation mentioning allowed characters.
If a remote actor has no icon, we show our local default icon.
If we have no icon, we should allow remote instances to show their
default icon, instead of sending ours.
In Chrome, I get the following when trying to use the remote follow form:
Refused to send form data to 'https://example.com/remote_follow'
because it violates the following Content Security Policy directive:
"form-action 'self'".
It seems some browsers (but notably not Firefox) apply the form-action
policy to the redirect target in addition to the initial form
submission endpoint. See:
https://github.com/w3c/webappsec-csp/issues/8
In that thread, this workaround is suggested.
