Conflicts:
- `app/controllers/api/v1/statuses_controller.rb`:
Conflict due to upstream adding a new parameter (with_rate_limit),
too close to glitch-soc's own additional parameter (content_type).
Added upstream's parameter.
- `app/services/post_status_service.rb`:
Conflict due to upstream adding a new parameter (rate_limit),
too close to glitch-soc's own additional parameter (content_type).
Added upstream's parameter.
- `app/views/settings/preferences/appearance/show.html.haml`:
Conflict due to us not exposing theme settings here (as we have
a different flavour/skin menu).
Took upstream change, while still not exposing theme settings.
- `config/webpack/shared.js`:
Coding style fixes for a part we have rewritten.
Discarded upstream changes.
* Improve description of privacy levels in compose interface
* Change strings in defaultMessage and source as well as english
Co-authored-by: Thibaut Girka <thib@sitedethib.com>
Conflicts:
- `Gemfile`:
We updated httplog in a separate commit.
Took upstream's change which updated it further.
- `Gemfile.lock`:
We updated httplog in a separate commit.
Took upstream's change which updated it further.
- `app/lib/sanitize_config.rb`:
Upstream added better unsupported link stripping,
while we had different sanitizing configs.
Took only upstream's link stripping code.
- `config/locales/simple_form.pl.yml`:
Strings unused in glitch-soc had been removed from
glitch-soc, reintroduced them even if they are not
useful, to reduce the risk of later merge conflicts.
* Change meaning of /api/v1/announcements/:id/dismiss to mark an announcement as read
* Change how unread announcements are counted in UI
* Add unread marker to announcements and mark announcements as unread as they are displayed
* Fixups
Conflicts:
- `app/serializers/rest/account_serializer.rb`:
Upstream added code too close to glitch-soc-specific followers-hiding code.
Ported upstream changes.
Change `all_day` to be a visual client-side cue only
Publish immediately if `scheduled_at` is in the past
Add `published_at` and `updated_at` to announcements JSON
* Move announcements above scroll container; add button to temporarily hide them
* Remove interface for dismissing announcements
* Display number of unread announcements
* Count unread announcements accurately
* Fix size of announcement box not fitting the currently displayed announcement
* Fix announcement box background color to match button color
* Add announcements
Fix#11006
* Add reactions to announcements
* Add admin UI for announcements
* Add unit tests
* Fix issues
- Add `with_dismissed` param to announcements API
- Fix end date not being formatted when time range is given
- Fix announcement delete causing reactions to send streaming updates
- Fix announcements container growing too wide and mascot too small
- Fix `all_day` being settable when no time range is given
- Change text "Update" to "Announcement"
* Fix scheduler unpublishing announcements before they are due
* Fix filter params not being passed to announcements filter
Conflicts:
- `Gemfile.lock`:
No real conflict, glitch-soc-only dependency (redcarpet) too close to an
upstream one (rdf-normalize)
- `README.md`:
we have different READMEs, discarded upstream's changes
- `app/views/admin/custom_emojis/index.html.haml`:
No real conflict, different context because of glitch-soc theming
- `lib/mastodon/statuses_cli.rb`:
Upstream added code to keep bookmarked statuses, we were already doing so
with slightly different code. Discarded upstream's changes.
- `package.json`:
No real conflict, glitch-soc-only dependency (favico.js) too close to
an upstream one
* Revert "persist last-intersected status update and restore when ScrollableList is restored"
This reverts commit 07e26142ef6a8e74bd2ac5e9b461a5a1699bd4c8.
accidentally merged spurious code in https://github.com/tootsuite/mastodon/pull/12661. https://github.com/tootsuite/mastodon/pull/12735 removes the slowdown that this code was trying to solve; and other functionality successfully restores the view state of the list
* Revert "cache currently-viewing status id to avoid calling redux with identical value"
This reverts commit c93df2159fbd3888a5c48d8a8b8ae61dbbc54b89.
accidentally merged spurious code in https://github.com/tootsuite/mastodon/pull/12661. https://github.com/tootsuite/mastodon/pull/12735 removes the slowdown that this code was trying to solve; and other functionality successfully restores the view state of the list
* Summary: fix slowness due to layout thrashing when reloading a large set of status updates
in order to limit the maximum size of a status in a list view (e.g. the home timeline), so as to avoid having to scroll all the way through an abnormally large status update (see https://github.com/tootsuite/mastodon/pull/8205), the following steps are taken:
•the element containing the status is rendered in the browser
•its height is calculated, to determine if it exceeds the maximum height threshold.
Unfortunately for performance, these steps are carried out in the componentDidMount(/Update) method, which also performs style modifications on the element. The combination of height request and style modification during javascript evaluation in the browser leads to layout-thrashing, where the elements are repeatedly re-laid-out (see https://developers.google.com/web/fundamentals/performance/rendering/avoid-large-complex-layouts-and-layout-thrashing & https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Performance_best_practices_for_Firefox_fe_engineers).
The solution implemented here is to memoize the collapsed state in Redux the first time the status is seen (e.g. when fetched as part of a small batch, to populate the home timeline) , so that on subsequent re-renders, the value can be queried, rather than recalculated. This strategy is derived from https://github.com/tootsuite/mastodon/pull/4439 & https://github.com/tootsuite/mastodon/pull/4909, and should resolve https://github.com/tootsuite/mastodon/issues/12455.
Andrew Lin (https://github.com/onethreeseven) is thanked for his assistance in root cause analysis and solution brainstorming
* remove getSnapshotBeforeUpdate from status
* remove componentWillUnmount from status
* persist last-intersected status update and restore when ScrollableList is restored
e.g. when navigating from home-timeline to a status conversational thread and <Back again
* cache currently-viewing status id to avoid calling redux with identical value
* refactor collapse toggle to pass explicit boolean
Conflicts:
- `config/locales/en.yml`
No real conflict, upstream added a translatable string “too close” to
one specific to glitch-soc
- `lib/mastodon/statuses_cli.rb`
Fixes made upstream, while changed in glitch-soc to keep bookmarked statuses
- `package.json`
No real conflict, additional dependency in glitch-soc
Conflicts:
- package.json
Not really a conflict, caused by an additional dependency in glitch-soc.
- yarn.lock
Not really a conflict, caused by an additional dependency in glitch-soc.
* Show badge on group actor in WebUI
* Do not notify in case of by following group actor
* If you mention group actor, also mention group actor followers
* Relax characters that can be used in username (same as Application)
* Revert "Relax characters that can be used in username (same as Application)"
This reverts commit 7e10a137b878d0db1b5252c52106faef5e09ca4b.
* Delete display_name method
* Fix poll options not being selectable via keyboard
Fixes#12384
* Improve styling of poll option checkboxes/radio buttons
* Use more appropriate ARIA roles for poll options
* Allow switching between single and multiple choice from keyboard
* Coding style
* Avoid using .bind()
* Add follow_request notification type
The notification type already existed in the backend but was never pushed
to the front-end. This also means translation strings were also available
for the backend, from the notification mailer.
Unlike other notification types, these are off by default, to match what
I remember of Gargron's view on the topic: that follow requests should not
clutter notifications and should instead be reviewed at the user's own
leisure in the dedicated column.
Since follow requests have their own column, I've deemed it unnecessary to
add a specific tab for them in the notification quick filter.
* Show follow request link in single-column if there are pending requests, even if account isn't locked
* Push follow requests from notifications to the follow_requests list
* Offer to accept or reject follow request from the notification
* Redesign follow request notification
