If the request errored, neither the then clause refetching fav
details was executed, nor did we receive new status data with
the correct state for ourselves. This left just the "optimisticly"
hallucinated success state from the FE, making it _seem_ like
everything went through fine for the user, while in reality
their action never actually registered.
This was highly misleading.
Since the issue only occurs sporadically it’s hard to be 100% certain,
but barring backend bugs or unforseen other parts of the FE interferring
this should fix disappearing (but successfull) favs and repeats.
Fixes: AkkomaGang/akkoma-fe#370
In unfortunate timing edge cases the deletion request could in theory
be processed first and the status get lost before its details
can populate the new post draft form.
Fixes: AkkomaGang/akkoma-fe#502
There is no limit on accepted remote poll option count
and even for same option count individual texts can be quite long.
Flex items seem to deal with margins differently than the previous
display type. Before the margins were overlapping, now margins are
separate. Thus the vertical poll-option margin needed to be halved
to preserve the visual appearance.
Unlike for posts, the collapse button is placed at the top
to make it easier to collapse it back for ridiculous lengths
where scrolling all the way down takes too much effort.
Perhaps status text collapsing should be changed to match this.
Fixes: AkkomaGang/akkoma-fe#495
Instead of needing to view post in a separte context without login
or going to the source instance for remote posts. There’s in theory
and argument to be made about knowing the current results influencing
one’s own vote, but (a) it’s already possible to view results anyway,
just mroe convoluted and (b) sometimes one has no opinion or does not
fit the criteria for desired voters and thus won't/shouldn't vote but
is still interested in seeing what eligible voters thought.
Disabling the show result button if in the process of voting
is mostly just meant to prevent misclicks when trying to submit
ones vote. Since both end up showing the results the mistake might
go easily unnoticed.
With the user-oriented FE docs being down,
it’s otherwise quite hard to discover the syntax.
Ideally the backend would provide the localised syntax description
for just the actually active provider. Then there’d be no need for
regular users to care about the configured backend provider.
If the (english version of the) description is located in the
same module as the provider logic, the chances of it staying
in sync with logic tweaks and other updates is much higher too.
Furthermore, this would allow alternative backends like Iceshrimp.NET
to provide an appropriate syntax hint without special client effort.
However, this requires much more back- and frontend plumbing.
Future contributions to improve it in this regard are warmly welcome,
but until someone is willing to work through all the necessary bits,
an exhaustive, purely client-side hint is at least better nothing at all
For performance reasons, limit it only to single-type queries though.
This avoids requerying already finished or irrelevant types
over and over again. In the future once the backend supports it
we might even be able to utilise id-based key pagination instead of
the more costly offset pagination.
Matching the default backend config,
unauthenticated users are not allowed to paginate.
Due to using offset pagination and the API result contianing several
independent lists, we cannot use the existing loadMore infrastructure
instead requiring bespoke pagination logic and UI.
We no longer force searching all types at once
and finally expose some control knobs the backend
supported for ages already.
This can make search faster (no need to search categories
you don’t care about) and more precise.
Furthermore, logged-out users will no longer be able to request
fetching _new_ remote content matching the default restrictions
of the backend.
Due to inflated processing cost, logged-out users also won't
be able to search all categories at once. Though, this is not
hard enforced and can be circumvented via query URL parameters.
This should now cover everything Iceshrimp.JS supports
with the exception of sparkle and followmouse if encoded properly.
(Or at least, everything advertised in it’s "mfm-cheat-sheet" page.)
The display for unixtime differs a bit, but matching it exactly should
not be critical as it seems not too useful for complex MFM animations.
The followmouse directive requires client-side scripts to be permanently active
and to make sense components must be allowed to leave their status. Both are
not desireable; no support for it is planned.
As implemented by Misskey, sparkle spawns and removes new animated SVG elements
at seemingly random positions around the source. We do not want permanently active
client scripts, so this cannot be copied.
It might be possible to replace this with a static animation yielding a
suffiently similar appearance. However, we’ll still need to add
additional elements during load for this which will cause issues if MFM
support is disabled or changes enabled state at runtime.
Alternatively limit ourselves to at most two simultaneous sparkles
(per element) relying on animated ::before and ::after pseudo elements.
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: AkkomaGang/akkoma-fe#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: AkkomaGang/akkoma-fe#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: AkkomaGang/akkoma-fe#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 AkkomaGang/akkoma-fe#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
AkkomaGang/akkoma-fe#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: AkkomaGang/akkoma-fe#367
Fixes: AkkomaGang/akkoma-fe#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.
It was not easily available in the narrow "mobile" interface
until now since both the desktop_nav and top nav panel are hidden.
Placing bookmarks after lists is consistent with the top nav panel
(though the top nav panel also puts interactions before both).
The recently removed "direct" timeline was similarly unavailable,
but its replacement, dm conversations, was already added to the
side drawer upon its introduction.
Fixes: AkkomaGang/akkoma-fe#474
Thirty seconds is much quicker than any other auto-refreshes in the
interface. Emitting a request for every users and tab with the poll
loaded this frequently can add up to a noteworthy total on the backend.
This is significantly worsened by our backend currently synchronously
fetching and updating the status of remote polls when queried about
while initiating a remote fetch for every incoming request inbetween
the last refetch passing the age threshold and the first current fetch
suceeding and completing its db transaction.
In preparation to an eventual switch to native Masto API format,
as well as flexibility to backends without the extension,
the entity normaliser just copies the count paramter to the same path
The current user info fetcher will also be used for
total unread DM counts in the future.
To avoid any future mishaps with improperly stopped fetchers etc,
this does not use the existing 'setCurrentUser' method but a new
update method with a safeguard against accidentally changing the
identity.
This replaces the removed "direct" timeline.
Curtnetly this is a read-only interface missing ways to
mark conversations as read, dismiss/delete conversations
or modify the core members of a conversation.
Future work may also add QoL stuff like automatic implicit addressing of
core members or (provided another backend extension) add messages to a
conversation without replying to something particular.
It has been long deprecated and even already removed from Mastodon
and our existing implementation suffers from bugs (at least on
large/some instances), see:
AkkomaGang/akkoma#798
Except for pleroma-derived web frontends, other clients generally don't
seem to make use of this timeline either, often also omitting an
interface for the conversations API.
Even if it worked properly, this isn’t the best way to present
DMs as all threads with different participants or topics are mixed
together in one linear timeline. The conversations API which suceeded
it in Mastodon and our backend already supports offers a much better
interface.
Fixes regression in f2c55423fd.
Ideally, this would only set state for what was actually changed
rather than rewriting the entire storage each time, which would also
have avoided this issue.
The fix is somehwat hacky not working with an empty path list or
parsed/internal fields not at the top-level of a path, but in practice
this seems to be always called with well bheaving paths. Should this ever
become an issue, this should migrating to the overall saner updating
approach described in the preceding paragraph.
Note: the cloneDeep call was originally added in
a97c07bfdf as part of
https://git.pleroma.social/pleroma/pleroma-fe/-/merge_requests/1385
Though it is not clear why setState would mangle its data argument
as it supposedly does to necessitate this copying.
As of Node 25, corepack will no longer be included by default in
the distribution:
https://github.com/nodejs/TSC/pull/1697
A separate corepack package is already available in npm, which
should work the same as the corepack that was included in Node 24
and prior.
The rest of the build instructions should remain the same.
This makes any filter that starts and ends in forward slashes act as a
regex filter instead of a simple substring filter.
In case any existing plain-text rule already matches this
it will need to be updated adding an additional layer of slashes
and escapes as needed. However, this is thought to be sufficiently uncommon.
Instead of using trailing flags as modifier complicating parsing further,
any modifications to regex matching must be done via local modifiers. See
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Modifier
Visibility scopes have no total order, but the function signature
of a compare function implies/requires such.
This led to the scope selector showing "local" as a possible option
on some original post scopes it was not actually compatible with.
The negotiated initially selected value was already correct though.
Was noticeable by e.g. the scrollbar being shown somewhere inside the
container and not being able to scroll near the edges if each line of
text was sufficiently short.
Directly implements the suggesstion from
AkkomaGang/akkoma-fe#456 (comment)
The upload call hid errors and the entity normaliser lets them pass
through as well (assuming it must be an already "correctly" formatted
legacy qvitter response), which led to errors being added to the the
draft as if it was a valid attachment object.
On later use of this error exceptions occur breaking the frontend and
due to being saved as part of a draft this could only be recovered by
clearing local client data.
Fixes: AkkomaGang/akkoma-fe#339
This is the canonical reference to a post and works best for lookups on
other servers. Previously this canonical ID was not accessible from the
frontend at all.
The "source" button continues to redirect to the preferred display URL
though (if set), since this is as the name suggests the preferred URL
for viewing the post in a browser (it might however not work when the
source instance restricts unauthenticated access even to local content).
This lifts the redundancy between the "source" and "copy link" buttons.
Since the legac qvitter API is still accounted for in the entity
normaliser, we just assume its external_url serves as both the canoncial
location and preferred display URL. It is dubious however, if this
codepath can even still be triggered at all and it likely makes more
sense to purge all remnants of the legacy API from the codebase.
Resolves: AkkomaGang/akkoma-fe#166
This reverts commit e1b4d8f59a
and obsoletes commit c2db0e66ef
which already unset min-height in notifications where this
caused images to become effectively invisible.
Image previews are currently designed to always show the full image
scaled down as needed. With min-height though they were allowed to
take the full width even if it caused overflows in vertical direction.
This happened to look kind of fine with only easy-to-miss overflows
in the main post view if each preview row had the same amount of
columns, but creates jarring overlaps otherwise.
Fixes: AkkomaGang/akkoma-fe#456
The media modal was changed to use still_image, but the attribute
pointing to the image load event handler wasn't updated.
This causes the modal to remain in the loading state forever.
Fixes: f48138c979
Instead, just also prefill the text wuth the user handle
for pure mentions.
This lead to us sending a boolean status id to the backend
which presumably only didn't cause problems in *oma backends
because API spec validation dropped the value with a mismatched type.
On an Iceshrimp.NET backend this caused errors to pop up.
There are more conditions gated by replyTo in the post form but
no longer triggering them doesn't seem to have any noticeable effect.
The one noticeable change being mentions now share a draft save slot
with regular message composing (before all mention messages shared the
same reply:true slot), but this seems sensible enough.
At least modern versions of corepack'ed yarn
(as build instructions tell use to use)
reaaally want to add this to the lockfile,
so let it do so to not need to constantly
be wary of uncommited changes here.
We don’t need them after initial account registration
and they just clutter the database otherwise
Together with the preceding commit this should get the
flood of garbage tokens into our database under control.
(We still want to fix the backends cleanup of old,
already existing tokens though)
Fixes: AkkomaGang/akkoma-fe#429
Original commit amended with a fix for registrations;
they need to (now) create an app and fetch an app-only token
before doing anything else, as this endpoint requires such a token.
Co-authored-by: Oneric <oneric@onierc.stub>
Cherry-picked-from: 0e25b94186
This only worked in *oma due to legacy session-cookie auth kicking in
(which we should really get around to fully purge).
Cherry-picked-from: e8896fad15
The frontend assumes these URLs will be relative to the target instance,
which may not be the case for non-*oma backends like Iceshrimp.NET
due to the backend storing emoji in an external object storage depending
on configuration.
Cherry-picked-from: c147c2aeb3
If I'm replying to a post in Klingon, chances are I'm going to write in
Klingon. This reduces friction for properly marking post language in a
conversation.
This fixes random actions being triggered by the enter key while the
subject field is focused.
When pressing enter, the browser simulates a click on the first "submit"
button it finds in the form.
A submit button is a button without `type="button"` set.
Remediate this by setting the type attribute on all but the "Post"
button.
Additionally, inhibit the enter key in the subject field (ctrl+enter
still works).
Currently translated at 72.0% (758 of 1052 strings)
Co-authored-by: Deleted User <noreply+21@weblate.org>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/ja_EASY/
Translation: Pleroma fe/pleroma-fe
Currently translated at 100.0% (1052 of 1052 strings)
Co-authored-by: Poesty Li <poesty7450@gmail.com>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/zh_Hans/
Translation: Pleroma fe/pleroma-fe
Currently translated at 100.0% (1051 of 1051 strings)
Co-authored-by: Poesty Li <poesty7450@gmail.com>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/zh_Hans/
Translation: Pleroma fe/pleroma-fe
Currently translated at 19.6% (207 of 1051 strings)
Co-authored-by: Hasan Yıldız <hasanyildiz0@yaani.com>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/tr/
Translation: Pleroma fe/pleroma-fe
This allows discerning how many voters agreed
with an option and aligns with other clients.
However, a backend bug makes this impossible for
remote multiple choice polls, so retain current
behaviour for anything affected.
In a status, we can choose to translate the status (assuming there's a translator enabled on the backend)
It will translate, in practice generally according to detected language, and also provide an option to override the source language.
Translating can take a while, and there wasn't really a visual feedback when it was translating.
Now the translate button will be dissabled while translating.
The code to turn mdm-data-* attributes into a value for the style attribute is complex.
I wrapped it in it's own function now for better code readability.
A comment was already provided with what the code intents to do and why, this information has also been moved
to this function.
Currently translated at 99.7% (1046 of 1049 strings)
Translated using Weblate (Polish)
Currently translated at 99.7% (1046 of 1049 strings)
Co-authored-by: ? <akkoma@mkljczk.pl>
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: subtype <subtype@hollow.capital>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/pl/
Translation: Pleroma fe/pleroma-fe
Currently translated at 8.1% (86 of 1049 strings)
Translated using Weblate (Lithuanian)
Currently translated at 5.5% (58 of 1049 strings)
Translated using Weblate (Lithuanian)
Currently translated at 1.9% (20 of 1049 strings)
Added translation using Weblate (Lithuanian)
Co-authored-by: Vaclovas Intas <Gateway_31@protonmail.com>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/lt/
Translation: Pleroma fe/pleroma-fe
During code review a much better way was pointed out to do the emoji scaling, by using `em`.
*key uses 2em for emoji, which is smaller than Akkoma has. I now kept the 38px for Akkoma,
but when "zoom" (ie x2, x3, x4, tada) happens, we set to 2em and zoom from there.
This fixes drafts not clearing after posting a reply.
Vue 3.3.11 changed watchers to stop firing after component unmount.
After posting a reply, the post form is removed, now causing the queued
event to be discarded.
Synchronous flush causes the handler to be called immediately when
changes happen, solving the problem.
The performance impact of this change seems non-existent. Even before,
typing would generate an event for each keystroke. Pasting is atomic.
See: https://github.com/vuejs/core/pull/7181
See: 80e2128d52
Fixes: a7dea2f70fFixes: #413
For some strange reason, after a mention a quote would be double as high as it should.
Removing this "pre-wrap" seems to fix this. I'm not sure what it was exactly for, but I don't see anything break.
The code blocks now don't wrap any more, but show a scroll bar, which imo is better for a code block.
Blockquotes are blocks, so not wrapped in an extra p-tag.
In statusses this gave an unfortunate result that the margins were different.
A p-tag has a bottom margin of 1em. Blockquotes had 0.2em top and bottom.
So under a paragraph there was 1em space, but under the blockquote, there was only 0.2em space.
The last p-tag has 0 margin at the bottom.
This commit basically does the same thing for blockquotes now, making it more consistent.
One difference is that the blockquote has a left margin of 0.2em because a little "jump"
in makes it look a bit better imo.
In code review it was decided that faint text for blockquotes should be used.
I copied how it was done in other places to faint text.
When making a theme for *oma-fe, there's a check for how readable things remain.
I'm unsure how that exactly works, but timestamps for a status is also faint,
so by using the same way of doing this, this should also be taken into account
for the theming engine.
An instance may restrict access to the public timeline (among others)
to authenticated users and there already is a setting to decide which page
to show authenticated and unauthenticated viewers by default each.
However, the logout redirect didn't honour this setting
leading to potentially broken pages and errors on logout
Previously quoted text (e.g. in Markdown `> Some text`) was italic
When two different quotes were made, there was no destinction between the two, making it look like one quote
This is confusing
Now we have a vertical line in front of the quote
When two different pieces of text are quoted, it is now clear because the lines are separated
This vertical line is a typical way of visualising quoted text, so it should be easy to understand what it is
For colour in MFM attributes, we expected a `#`, but that's apparently wrong. The BE
translates the `color` attribute in `$[fg.color=000 text]` into `data-mfm-color=000`.
But for the SCSS to work, we need to put it in the style attribute as `--mfm-color: #000`.
Generally we just add the attribute value as-is in the `style` attribute, but now we
have a special exception for color so we add a `#` before the value.
We take the value from a data-* attribute and then add this to the style attribute.
This will probably be OK in most cases, but just to be sure, we check for "weird" characters first.
For now we only allow letters, numbers, dot, hash, and plus and minus sign, because those are the ones I currently know of who are used in MFM.
The data-* attribute remains because it was already considered proper HTML as-is.
When typing MFM, a sugestor drop-down appears so you can see and/or choose what MFM function to use
The new MFM functions we support have now also been added
The `span`'s needed an inline-block for the transform to wrok
I also added an `overflow: hidden;` because these functions can make the text go beyond the borders of the StatusBody
With `overflow: hidden;`, it won't show outside of the borders
These now work for the new, FEP-c16b compliant, representation
Nesting also works
It already worked for text and "normal" emoji, but now it also works for custom emoji
Things like `speed=0.1s` now work
I also noticed a class was set on StatusBody, but we don't use it, we use StatusContent.
Therefor I removed it now.
We do still pass the setting through StatusBody to RichContent bc it's used there to decide to not show greentext for arrows when MFM was used.
Note that while this setting still works
* You have to refresh the page to see it working (was already like this, so I didn't touch it here)
* It explicitly checks for content type. If womeone provides MFM-like HTML, then it will still show as greentext if that option is enabled
I think it's a bit inconsistent, but otoh, the inconsistency to me seems more that we ignore the greentext option for one input type specifically
I do still notice generall bugs with MFM.
* Position doesn't seem to work, neither does scale.
* There also seems to be a regression where custom emojis don't become larger any more with e.g. `$[x2 :hehe: ]`
I don't assume the regression is made in this commit, so I add this already. The rest needs to be fixed before merging.
The SCSS that we took from Foundkey in a previous commit, is now working
The settings for disabling MFM or only show animation on hover are working
The previous representation also works and it's clearly marked in the code what is legacy
All the MFM SCSS is now located in one file specifically for MFM, ./src/components/status_content/mfm.scss
This is only SCSS:
* The variables who are provided as data-attributes are not working yet
* `sparkle` also doesn't work
This is part of a bigger work to fix MFM in Akkoma
See <AkkomaGang/akkoma#381>
Here we add the MFM stylesheet as it is used by Foundkey
See <b22e627089>
Foundkey uses MFM and both the Founkey and Akkoma projects and communities, have historically been closely related
As such it makes sense to start with feature-parity with Foundkey
This commit only adds the stylesheet so that correct attribution is given
Properly integrating and making it work will happen in later commits
MFM was defined in three places.
There was ./src/components/status_body/status_body.scss => I moved this to ./src/components/status_content/mfm.scss
There was ./src/components/status_content/status_content.vue => I moved this to ./src/components/status_content/mfm.scss
There's ./static/mfm.css => I kept this as-is
./src/components/status_content/mfm.scss is now being loaded in ./src/components/status_content/status_content.vue
I added a comment in both ./src/components/status_content/mfm.scss and ./static/mfm.css referencing each other
Note that this is just a first step in an overhoal of how MFM is handled. It seemed easier to do this as a first step and then build further on that.
For someone who isn't used to building fe things like this, it's
not always clear to install Node.js or what version.
A line has been added to the installation instructions pointing to
resources where to get it and what version to use. For version I
point to the woodpecker config because that is what the CI uses and
therefor always "tested".
There was a file .node-version who contained a node version, but
this was seriously outdated and removing it didn't seem to break
anything. Assuming it indeed doesn't do anything any more, it seems
better to remove to avoid confusion.
Previously restoring from file would also restore the old version value
breaking upload of the new settings to the server.
Additionallly it didn’t even attempt to sync settings after restore and
was insufferably slow due to individually updating every single setting
with a dispatch. Instead only update changed settings like on server
syncs which usually speeds the process up considerably.
Fixes: AkkomaGang/akkoma-fe#405
If someone repeating a post had a long username, their username would
overflow beyond the bounds of the post.
This fixes this isse by turning the bar displaying the username and
repeat icon into a flexbox.
The backend returns them order by when the post was favourited;
reordering them by post date jumbles everything up each addition
and serves no purpose.
Fixes: AkkomaGang/akkoma-fe#391
Currently translated at 91.9% (964 of 1048 strings)
Translated using Weblate (Vietnamese)
Currently translated at 92.2% (965 of 1046 strings)
Translated using Weblate (Vietnamese)
Currently translated at 92.2% (965 of 1046 strings)
Translated using Weblate (Vietnamese)
Currently translated at 84.3% (882 of 1046 strings)
Translated using Weblate (Vietnamese)
Currently translated at 84.3% (882 of 1046 strings)
Translated using Weblate (Vietnamese)
Currently translated at 79.8% (835 of 1046 strings)
Translated using Weblate (Vietnamese)
Currently translated at 79.8% (835 of 1046 strings)
Co-authored-by: Nguyễn Gia Phong <cnx@loang.net>
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: xarvos <huyngo@disroot.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/vi/
Translation: Pleroma fe/pleroma-fe
Currently translated at 100.0% (1048 of 1048 strings)
Merge branch 'origin/develop' into Weblate.
Translated using Weblate (Chinese (Simplified))
Currently translated at 100.0% (1046 of 1046 strings)
Co-authored-by: Poesty Li <poesty7450@gmail.com>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/zh_Hans/
Translation: Pleroma fe/pleroma-fe
Currently translated at 99.7% (1045 of 1048 strings)
Translated using Weblate (Polish)
Currently translated at 99.7% (1045 of 1048 strings)
Translated using Weblate (Polish)
Currently translated at 100.0% (1046 of 1046 strings)
Translated using Weblate (Polish)
Currently translated at 100.0% (1046 of 1046 strings)
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: subtype <subtype@hollow.capital>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/pl/
Translation: Pleroma fe/pleroma-fe
Currently translated at 80.4% (841 of 1045 strings)
Translated using Weblate (Italian)
Currently translated at 65.3% (683 of 1045 strings)
Co-authored-by: Cuche <cuche@mailbox.org>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/it/
Translation: Pleroma fe/pleroma-fe
Currently translated at 100.0% (1048 of 1048 strings)
Translated using Weblate (Chinese (Traditional))
Currently translated at 99.2% (1040 of 1048 strings)
Co-authored-by: Toot <toothpicker@users.noreply.translate.akkoma.dev>
Co-authored-by: Weblate <noreply@weblate.org>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/zh_Hant/
Translation: Pleroma fe/pleroma-fe
Currently translated at 93.7% (983 of 1048 strings)
Translated using Weblate (Spanish)
Currently translated at 93.9% (983 of 1046 strings)
Translated using Weblate (Spanish)
Currently translated at 92.5% (967 of 1045 strings)
Co-authored-by: Weblate <noreply@weblate.org>
Co-authored-by: taretka <info@tarteka.net>
Translate-URL: http://translate.akkoma.dev/projects/akkoma/pleroma-fe/es/
Translation: Pleroma fe/pleroma-fe
This pulls in 267 new emoji:
- all 258 non-deprecated country or macro region
flags (composed by two regional indicators)
- all 3 regional flags currently recommended for general use
(Wales, Scotland, England)
- a few random ones i picked out
- goose
- heart on fire
- heart mending
- transgender flag
- rainbow flag
- pirate flag
The new names are derived from official Unicode names
with minor modifications to fit into the usual shortcode scheme
and dropping the flag_ prefix from country indicators.
Due to a naming conflict the old "japan" emoji
U+1F5FE SILHOUETTE OF JAPAN was renamed to "japan_silhouette".
Easy Japanses (ja_easy) and traditional Chinses (zh_Hant) use
(custom) non-ISO codes in the interface. Because MastoAPI only accepts
ISO 639 codes, the backend will return an error rendering users
unable to do anything unless the post’s language was explicitly set.
It was merged into pleroma-fe on 2022-02-03 in
76547fe66d and imported
into akkoma-fe on 2022-06-08 with the merge commit
f6cf509a04.
However, something went wrong in the merge and while the setting
and its infrastructure exist, it is never used anywhere and @ is
always displayed as text.
Given it existed in this broken state for nearly one and a half years,
never worked on akkoma-fe and no bugs were filed about this, it appears
nobody cares, so let’s just remove it.
Notifications about favourites and follows use .notification-right,
notifications about replies instead use .heading-right.
Previously only the former set a min-width, however the
chosen value of 3em was too small to fit the worst case.
As a consequence, when the timestamp text changes over time,
its element width changes, which may result in neighbouring text
(no longer) needing to wrap to a new line in turn changing the size
of the whole notification box pushing older notification boxes down/up.
These constant movements at the side of the screen can be quite
annoying and confusing when the cause cannot be immediately discerned.
Avoid this, by reserving enough space for any timestamp.
For English, the worst case is the five-character 'XXmin', since the
short identifier for minutes is the longest with three letters.
With two exceptions, all other current localisation also do not exceed
three letters in any short unit identifier up to days.
However, some localisations (e.g. Polish) additionally insert a space
between numerical value and unit. This matches SI recommendations
pushing the worst case to 6 characters.
6 characters will be sufficient for timestamps up to 3 weeks in all
languages (minus prev exceptions), which seems reasonable enough
as beyond this timestamps rarely change anyway.
The aforementioned exceptions being Vietnamese and Occitan,
but in the current localisation all or the relevant short unit
identifiers are identical to the long forms indicating this is
just due to incomplete translation.
Indeed, Vietnamese Wikipedia (read through machine translation) suggests
“ph” is commonly used as unit identifiers for minutes, but the current
localisation fully spells it out as “phút”.
Currently all notifications except follow-related once include
and explicit direction text. (It missing in follow notifs is due to an
omission in 804ba0cdb6b353e0c959c68f44c6a1316c0d6b10 which only added
the newly introduced with-direction to status-related notifs. Before,
presumably all notifs included direction text.)
But in the notification tray horizontal space is scarce
and notifs can already be assumed to only come from the past.
While it might not be too bad for the English localisation’s 4-letter
' ago' suffix, e.g. the Indonesian localisation’s ' yang lalu' needs
10 letters.
Thus instead of fixing the omission for follow-related notifs,
drop direction text from all notification timestamps.
Modern browsers start to tighten down on third-party access to cookies.
E.g. in current Firefox, a warning about the userLanguage cookie was
shown since it did not yet explicitly set the SameSite attribute and the
default is about to change.
The cookie name being referred to as BACKEND_LANGUAGE_COOKIE_NAME
suggests it should be readable by the actual Akkoma backend, which can
live at a different domain than akkoma-fe. Thus explicitly enable
sharing with third-party sites.
No warnings were shown for other cookies, so I assume
this was the only one not yet setting SameSite.
@ -8,7 +8,7 @@ This is a fork of Akkoma-FE from the Pleroma project, with support for new Akkom
# For Translators
The [Weblate UI](https://translate.akkoma.dev/projects/akkoma/pleroma-fe/) is recommended for adding or modifying translations for Akkoma-FE.
The [Weblate UI](https://translate.akkoma.dev/projects/akkoma/pleroma-fe/) is recommended for adding or modifying translations for Akkoma-FE.
Alternatively, edit/create `src/i18n/$LANGUAGE_CODE.json` (where `$LANGUAGE_CODE` is the [ISO 639-1 code](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) for your language), then add your language to [src/i18n/messages.js](https://akkoma.dev/AkkomaGang/pleroma-fe/src/branch/develop/src/i18n/messages.js) if it doesn't already exist there.
@ -20,9 +20,11 @@ To use Akkoma-FE in Akkoma, use the [frontend](https://docs.akkoma.dev/stable/ad
## Build Setup
Make sure you have [Node.js](https://nodejs.org/) installed. You can check `/.woodpecker.yml` for which node version the Akkoma CI currently uses.
``` bash
# install dependencies
npm install -g yarn
npm install -g corepack
yarn
# serve with hot reload at localhost:8080
@ -37,7 +39,7 @@ npm run unit
# For Contributors:
You can create file `/config/local.json` (see [example](https://git.pleroma.social/pleroma/pleroma-fe/blob/develop/config/local.example.json)) to enable some convenience dev options:
You can create file `/config/local.json` (see [example](https://akkoma.dev/AkkomaGang/akkoma-fe/src/branch/develop/config/local.example.json)) to enable some convenience dev options:
* `target`: makes local dev server redirect to some existing instance's BE instead of local BE, useful for testing things in near-production environment and searching for real-life use-cases.
* `staticConfigPreference`: makes FE's `/static/config.json` take preference of BE-served `/api/statusnet/config.json`. Only works in dev mode.
@ -52,4 +54,5 @@ Edit config.json for configuration.
### Login methods
```loginMethod``` can be set to either ```password``` (the default) or ```token```, which will use the full oauth redirection flow, which is useful for SSO situations.
```loginMethod``` can be set to either ```password``` (the default) or ```token```, which will use the full oauth redirection flow, which is useful for SSO situations.
