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
One user suggested that the loading indicator should not be written
ALL CAPS, at first it was thought this change is very minor, but then
a few other people asked agreed on the same thing - variant without
caps looks better. It may be related that it is harder to read or just
looks too "catchy". Moreover, I asked @rf@mastodonsocial.ru community
what they think of that and 82% of 22 people agreed on this change.
This commit removes all usage of text-transform: uppercase, where the
font size specified, it changes the value by one pixel larger, so we
still keeping the "designed" size of the labels but without using CAPS.
This commit changes margins of the page heading header, actions in
order to fix displaying with low screen size and long enough header.
It is working by giving heading and action buttons margin from top
and then negating it in parent element. Whenever flex item wrap, the
"negated" margin will be applied again, providing us nice space
between header and action buttons.
This commit also adds a margin to header, so it does not clamp with
the heading actions and they wrap a little earlier (15px ahead). As
well as the left margin is not anymore applied to the first action.
This commit:
- Refactors centered text blocks currently used for placeholders
for empty tables and puts styles for it in separate class -
.centered-text, simply aliasing text-align: center. Which is
furtherly used in this commit.
- Improves applications settings page to use heading actions, moving
"New application" button there, and displaying placeholder "You
have no applications" in place of empty table.
- Improves custom emoji settings page to use heading action
for "Upload" button, making it more easily accessible without
need to scroll through all of the emojis.
- Improves email domain blocks settings page, moving "Add new" to the
heading actions and using placeholder "No e-mail domains currently
blacklisted" instead of showing empty table.
Conflicts:
- `app/controllers/application_controller.rb`:
Conflict due to theming system.
- `app/controllers/oauth/authorizations_controller.rb`:
Conflict due to theming system.
* 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
Fixes#12607
`will-change: transform` apparently makes manual scrolling impossible on
Firefox/Windows. While this should probably be considered a Firefox bug,
`will-change: transform` seem like a very aggressive performance hint that
may possibly make the browser consume more resources than needed, especially
in multiple-column mode.
This was originally added to improve scrolling performances on mobile, but
I think this isn't necessary anymore, because of the two following reasons:
- `contain: paint` (which is implied by `contain: strict`, which we apply
whenever the browser supports grids) should have similar effects
- in single-column mode, the scrolling container is the root element, which
I believe is optimized in at least Chromium
Keep in mind that I have not been able to make in-depth benchmarks, and
especially not been able to try on mobile, so performances should probably
be investigated further…
* Move resolved button to the heading
This is one of the commits on improving overall reports page structure.
It changes where resolved button is located, moving it to the heading,
right next to the "Report #n" header, so-called "hot-place" to look at.
To accomplish this we have to declare one more content variable, change
admin dashboard template to respect it and CSS files for minor styling,
so buttons are inlined and centrally aligned according to the heading.
* Move actions buttons below the report table
I believe that actions to react on report should not be located at the
top of the page, instead they should be either after the table or
reporter's comment. This is just a logical sign that you should not
react to the report without reading all the details first.
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 7e10a137b8.
* 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
