No longer will long bios end up zooming in
on just a tiny fraction of the banner.
Instead always fit it to the width and let the height adapt as needed.
This however means we can no longer rely on the image filling the
entire height, therefore gradient and masking logic for smooth
transitions had to be reworked as well.
Else code text is adjoined to the vertical codebock border.
Also use explcitit "scroll" for odd browsers completely hiding the
scrollbar otherwise. One could argue "auto" still being more correct
since this matches what is evidently the desired and preferd styling
by those browser vendors. But on the other hand user confusion from
this questionable styling decision seems more problematic and already
occurred.
Commit 65201e3000 added the mfm class
(back) to MFM posts to adjust emoji sizing and commit
ebe4158885 changed codeblocks to respect
the original line breaks allowing to scroll the code container.
However, we still carry CSS to display legacy MFM representations
and one of the legacy rules matched on just the mfm class changing
display to inline-block.
This caused code blocks to not become scrollable, but simply overflow
while at the same time pushing the logical line length for all other
text in the statuses so it may overflow too. This overflow then got
truncated making the post unreadable.
Fix this by renaming the MFM post indicator class
to avoid any overlap. This may potentially leave legacy MFM broken,
but further research needed to figure out why it chooses inline-block
display in the first place.
Mostly-resolves: #511
By default DOMPurify removes enclosing semantics and annotation
elements but retains their children by reparenting them.
This led to supposed to normally invisible source annotations
being rendered next to the proper math expression.
Fixes oversight in: d0135f4a71
Fixes: #509
There is no issue on current backends and
this simply doesn’t make any sense.
It lead to sometimes remote accounts _never_ showing up in the suggestor
if they were not in the first page of results for just the local
username part of their handle unless the account was already loaded
into cache by some other means beforehand.
We don’t want to kick of a barrage of remote request on the backend
attempting to lookup half incomplete nicks. Nor do we, in the client,
want the additional latency of waiting for the backend to finish those
futile network requests.
Eventhough the suggestor used to call the API with an explicit
resolve=true, no actual WebFinger lookups should’ve ever been
made due to the suggestor (otherwise) nonsensically stopping
backend queries if there was a remote domain fragment.
(Yes, "emoji_input" also handles user suggestions)
Fixes oversight in 4d578720e8.
Avatar upload logic is wrapped in an explicit Promise object and
thus cannot access the tab’s this object. Instead it uses an
indirection via a captured local variable "that" for all existing uses,
but this was overlooked for the added bits.
All other uploads do not use a cropper and are not affected
Fixes: #505
Using `--input` for codeblock backgrounds is not ideal, but the best we
can do with currently existing variables. Using colours not nominally
intended for text background risks borking on custom themes.
Among actual background colors we have
- the regular post background `--bg` which never provides distinction
- the background of _selected_ posts `--selectedPost` which
only offers a visual distinction for not selected posts
- Background of profile `--profileBg` which is only used in absence of
a profiel banner image — but Mastodon API requires us to _always_
have a banner image (so this color is not actually used and thus has
a higher chance of breakage)
- the background of input fields `--input`
The latter is well tested and almost certainly well legible
with a decent chance of creating a visual distinction.
Future patches to create a distinct new colour variable for codeblocks
and the plumbing in the theme editor welcome.
The old code was inconsistent about when the mention line state and
remembered spacing were reset as well as failing to add necessary
whitespace if a mention line was immediately succeeded by a plain text node.
The latter was kludgily fixd for a particular special case with the
last-child exception to whitespace trimming. (However this could en up
to retaining superfluous undesireable space in other cases)
This led to sometimes space being added "back" several times
notably leading to one extra, empty line in blockquote elements
succeeding mentions with whitespace. This stalled the otherwise
unrelated #412
Now we always reset the mention chain and remembered spacing together
and also add back spacing in front of plain text nodes if appropriate
obsoleting the last-child exception.
Previously it was only adjusted for effects involving scaling,
creating odd inconsistencies betwen e.g. an unstyled emoji and
a slow "tada" animation as well as reduced compatibility.
To ensure scaling still works for posts with FEP-c16b-like HTML
without the source type being actually indiated as (vanilla) MFM,
the 2em rule specific to scaling tags is retained too.
Long'ish values and keys are not too uncommon and this lead
to them becoming unreadable, the full text only accessible as a tooltip.
Overly long single words are still ellipsised to prevent overflow.
Just like the old NIH HTML parser this test wrongfully assumed
">" couldn't appear unescaped in tag attributes and thus was
broken for many months now after a browser upgrade in our CI runners
caused this to be quoted automatically anyway.
Instead test against actual injection attempts
of additional styling rules and new attributes.
The backend is already supposed to sanitize everything for us
and it is rather restrictive even. But it’s simple enough,
so lets make sure of it and lessen the real-world impact
should there ever be backend sanitizer bugs (if at all,
then most likely in fast_html or its HTML parser dependency)
DOMPurify can only return a body element or a DOcumentFragment
not a full document as DOMParser does. However we only ever
grabbed the body object anyway so let’s just return that directly.
The inhouse parser wrongly assumed tag attributes could not contain
literal '>' characters, has issues like the recently fixed
#480 and probably many
more problems. In any event the regex and characterwise parser mess was
hard to read and reason about.
Browsers already have optimised HTML parsers built in so use it.
Also rework the nested function into a parser class for even better
readability.
Other than using a proper HTML AST and rearranging everything into
a class this for the most part closely follows the previous logic.
More substantial logic changes were made to emoji processing and
green/cyantext styling.
The former now processes text in chunks to the next colon rather
than character by character. The latter is possibly a bit more
leient in what it styles now and no longer will break styling
tags enclosing a <br />.
The reverse pass basically only dealt with hastags and existed
to make detection of the "last" set of consecutive hashtags easier.
But since lastTags was never used and thus dropped in the preceding
commit, the whole pass is obsolete too.
We can simply parse hastags during the forward pass.
HTML tags can in fact contain '>' characters in quoted attribute values.
Besides that the regex replace failed to normalise whitespace
or to strip invisible elements. And lodash’s 'unescape' function
only replaces a limited set of quoted HTML entities, not all.
The computed localCollapseSubjectDefault was removed from status_content
about five years ago in 50aa379038. Ever
since this clause was effectively dead code but spamming Vue warnings.
It used to automatically reveal NSFW attachments already hidden behind
a collapsed content warning. However, this means it was impossible to
reveal just the text of a content warned post and we already have a
separate settings for always revealing NSFW media if desired, although
this admittedly will also reveal cw-less media directly.
Given there seemingly were zero complaints about the effective new
behaviour, let’s just drop the dead code conditional.
Ideally alt text and image would be handled together, but this is not
straightforward to do with the current profile tab and API interaction
setup.
To somewhat alleviate this, always submit the current matching alt text
too when uploading a new image. This allows an alt text edit before
confirming the upload to immediately take effect without the user
needing to remember to go back to the upper section to hit "save" there.
Only avatar alt text is integrated into the UI in an assistive way.
Header and backgrounds are set as CSS backgrounds and I don’t know
of a good way to add alt or aria-label attributes to that. Nor whether
it even makes sense to bake this into the default view since their just
decorative background elements.
The full al text can still be accessed through the new profile media gallery.
Despite many places setting distinct :title and :alt atttributes
for StillImage, it actually only had a :alt attribute used for both.
This is however not what we want here,
so add (back?) :title as a distinct property.
Related backend change: AkkomaGang/akkoma#1034
E.g. bridgy doesn’t federate the full MIME type and
it’s attachment URLs also have no extension. Thus
the full MIME type is always just a generic binary,
but since it still federates a more specific AP type
the generic Mastodon type still contains some information
we can use here to display it properly.
While at it, drop unused fileMatchesSomeType function.
Its last users disappeared in e654fead23.
Ref.: https://github.com/snarfed/bridgy-fed/issues/2198
Co-authored-by: Yonle <yonle@proton.me>
This used to cause null errors e.g. when initialising the accounts for a
newly created list, which also prevented a post-creation redirect to the
new list’s page from occuring.
Co-authored-by: Yonle <yonle@proton.me>
Fixes: #367
Fixes: #368
Mostly just reordering, whitespace changes
and removing superfluous "this".
eslint really wants us to add :key to the UserAvatar list in DM
conversation cards. With :key Vue will reorder elements instead
of patching their contents on list changes, allowing input state
of elements to be preserved. This doesn’t really seem relevant
here since USerAvatars do not have a state, but also not harmful.
One lint complaint about using double quotes at the outer level
was purposefully ignored as it results in needing to quote
double quotes within the string making it rather unreadable.
