Conflicts:
- `app/controllers/application_controller.rb`:
Conflict due to theming system.
- `app/controllers/oauth/authorizations_controller.rb`:
Conflict due to theming system.
* 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
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 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
* Fix lost focus after modal closes
Regression caused by the use of the wicg-inert polyfill
* Fix regression introduced by wicg-inert
* Catch errors to please CodeClimate
Counter size is currently set to strict 33.3% width, but with it
counter may break in other languages than English. For example it is
already broken on Gargron's profile on mastodon.social using Russian
locale.
This commit changes "width" to "min-width", so counters still displayed
correctly, but if they need more width to fit text, they are now allowed
to take as many width as they need.
The arguments were passed to the wrong function… also, there is no
need to have a conditional decrementation: failure to upload means
we marked an upload as pending, in all cases.
Takeshi Umeda