* Periodically save timeline markers
This saves timeline markers immediately upon message arrival, but not more
than once every 5 minutes.
This does not change how the markers are saved on closing the window,
except that it avoids submitting them if there is no need for it.
* Use the Fetch API when possible instead of XHR on window unload
Fixes#13573
For some reason (I suspect this may be related to focusing the item before it
got drown by the browser), Firefox scrolls to top when bringing up dropdown
menus with pre-selected items.
This commit uses the “preventScroll” option as, due to the placement behavior,
the menu should be visible anyway and not trigger scrolling.
Fixes#13536
- Expanding a paused video doesn't autoplay anymore
- Default volume level for the expanded video inherited from the original video
Position/playing state/volume are carried over from the original video player
to the modal, but they're not reported back to the modal as it would require
deeper changes.
This commit redesign the polls and increases characters limit for the
options from 25 to 50 characters, giving pollsters more freedom.
Summarizing, the redesign is making the polls more adaptive for upcoming
changes to the options characters limit: the bar, or a "chart", is now
displayed separately from the option itself; vote check mark is moved
next to the option text, making the percentages take less space. Option
lengths are taken into account and text is wrapped to multiple lines
if necessary to avoid overflow.
* Make the area to the left “Show Thread” also expand the toot in Web UI
* Clicking the left part of a conversation with the avatars now opens it in Web UI
This two-line change fixes a crash in the front end that occurred
under the following circumstances:
* A server had more than one announcement,
* A user was displaying the announcements, and
* An announcement was deleted (or unpublished, which amounts to
the same thing.)
As might be expected, the bug was caused by attempting to access a
notification using an index value outside the bounds of the existing
announcements. Specifically, in two places. First,
`_markAnnouncementAsRead` attempts to modify announcements based on
the current index. This is what caused the front end crash. Second,
when rendering the `Announcements` component, the code paginates the
announcements and displays the current one. This did not cause a
crash, but caused the front end to confusingly display a blank
announcement (in situations that would have caused a crash) with no
way for the user to navigate back to previous announcements.
This commit fixes both issues by adding a check to ensure that the
code never attempts to access an announcement with an index greater
than or equal to the number of announcements present.
* 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>
* 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
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
* 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
* 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
