Currently, middle-clicking on a hashtag search result will open a new
instance of the WebUI, which is inconsistent with middle-clicking on
an account result, or a hashtag in a toot.
* Allow to show a specific status in the admin interface
* Let the front-end know the current account is a moderator
* Add admin links to status and account menus
If the current logged-in user is an admin, add quick links to the admin
interface in account and toot dropdown menu. Suggestion by @ashkitten
* Use @statuses.first instead of @statuses[0]
The modal-handling code gives back focus to the element focused when the
modal opened. However, in the case of reply confirmation, it would do so
*after* the composer code itself requested focus.
* Always use the scrollable class for the ScrollList component
Fixes#9499 as well as empty timelines' scrollbar “blinking”
between loading state and empty state.
* Do not display empty message when the list is known to have more elements
Fixes#9500
* Fix LoadMore usage in account media gallery
(Even though that codepath is probably never actually used…)
* Make account media gallery more consistent with account timeline
Fixes#9498
Display “load more” more consistently, add a loading indicator on first load.
* Fix “load more” button when no data has been fetched
So that opening a profile feels faster. Also, pinned toots are not
shown before other toots have loaded. Also, if no toots are loaded,
added empty message
- Use object properties rather than component state for
mouseMovedRecently and scrollToTopOnMouseIdle flags
- Remove redundant scrollToTop prop call, also fixing an attempt to call
an undefined prop.
Fixes#9217
- On recent mouse movement, hold timeline position so statuses remain in
place for interactions in progress.
- If the timeline had been scrolled to the top before mouse movement,
restore scroll on mouse idle.
Reminder: Suggestions were added in #7918 and are based on who you
interact with who you do not follow. E.g. if you boost someone a lot
from seeing other people's boosts of that person, it makes sense you
might be interested in following the original source; or if you reply
to someone a lot, maybe you'd want to follow them
Each suggestion can be dismissed
* Add conversations API
* Add web UI for conversations
* Add test for conversations API
* Add tests for ConversationAccount
* Improve web UI
* Rename ConversationAccount to AccountConversation
* Remove conversations on block and mute
* Change last_status_id to be a denormalization of status_ids
* Add optimistic locking
* Revert "Fix some icon names changed by the Font Awesome 5. (#8796)"
This reverts commit 3f9ec3de82.
* Revert "Migrate to font-awesome 5.0. (#8799)"
This reverts commit 8bae14591b.
* Revert "Fix some icons names, unavailable in fontawesome5 (free license). (#8792)"
This reverts commit b9c727a945.
* Revert "Update the icon name changed by the Font Awesome 5. (#8776)"
This reverts commit 17af4d27da.
* Revert "Add bot icon to bot avatars and migrate to newer version of Font Awesome (#8484)"
This reverts commit 4b794e134d.
* Make dropdown animations respect their placement
Also fix the corner radius on the privacy dropdown button when using top placement
* Fix code style issue
This includes clicks on hashtags, mentions, display names and media in the
timeline; and usernames in reply-indicator, detailed status, and the boost
modal.
* Add keyword filtering
GET|POST /api/v1/filters
GET|PUT|DELETE /api/v1/filters/:id
- Irreversible filters can drop toots from home or notifications
- Other filters can hide toots through the client app
- Filters use a phrase valid in particular contexts, expiration
* Make sure expired filters don't get applied client-side
* Add missing API methods
* Remove "regex filter" from column settings
* Add tests
* Add test for FeedManager
* Add CustomFilter test
* Add UI for managing filters
* Add streaming API event to allow syncing filters
* Fix tests
* Remove Collapsable and use CSS instead
* Put the CW field between the toot we are replying to and the toot field
* Use same spacing between all fields in the composing column
* Adjust footer of getting started column
- Improved style
- Moved hotkeys, about this instance and logout to footer
- Removed FAQ, User Guide, Apps links
- Use hamburger icon for the column
* Add edit profile action button to profile and more to dropdown
* Add "Trending now" to getting started column
* Add preferences/security links on mobile layout
* Revert "Do not re-position scroll when loading more (inserting items from below) (#7344)"
This reverts commit 8c601b54cc.
* Revert "Prevent timeline from moving when cursor is hovering over it (fixes#7278) (#7327)"
This reverts commit 58852695c8.
* Mark currently selected privacy setting in privacy dropdown
* Prevent Enter keypresses from triggering dropdown display toggle twice
* Give focus to first/selected item of dropdown menus
* Implement keyboard navigation in privacy dropdown
* Implement keyboard navigation in generic dropdown menus
KeyboardEvent.key may be physical key name (Escape, Tab, etc.)
even in text composition and it causes hotkeys or suggestion selection.
So we need to check e.which or e.isComposing.
Checking e.which also allows us to avoid Esc key on compositionend in Safari.
This fixes following cases which causes hotkey action accidentally:
* hitting Esc key to cancel text composition (mostly in CJK)
Although events on cancelling composition are still heavily
browser / input method dependent, but this implementation would
covers current UI Events spec and some exceptions.
* hitting Esc key to close autocomplete suggestions
This PR changes to use keydown event instead of keyup event as well as other hotkeys.
* Fix: Switching between composing direct message and mention from menus
Previously clicking "direct message" followed by "mention" resulted in the composed status staying as "direct", along with weird spacing of items in the text area. This attempts to fix that.
* Fix: Add missing proptype check for onMention in Status component
* Add the ability to send a direct message to a user from the menu on Statuses
* Add space between "Embed" and "Mention" on expanded statuses menu
`navigator.share()` rejects Promise if user cancelled sharing, and it may
print it as an error on JavaScript console.
This patch ignores it and prints other errors on the console.
* Keep list of blocked domains
Might be overkill, but I'm trying to follow the same logic as for blocked users
* Add basic domain block UI
* Add the domain blocks UI to Getting Started
* Fix undefined URL in `fetchDomainBlocks`
* Update all known users' domain_blocking relationship instead of just one's
* Remove pointer events on the entire UI when a dropdown menu is open
This prevents operations to change the location of the menu such as
scrolling.
* Fix mistake from merge
onScrollToBottom was a function to run instead of onScrollToTop and
onScroll when scrolling to the bottom. The behavior to prevent
onScrollToTop was inconvenient because the viewport can be at the bottom
and at the top at the same time if the viewport is larger than the
container.
onScrollToBottom was also called when the button to load more is clicked
on contray to the name suggests, which led notifications and
status_list_container components to mark the scrolled location is not at
the top mistakenly.
onLoadMore is a replacement for onScrollToBottom. It will be called
independently from onScrollToTop and onScroll.
* Improved media modal
ImageLoader: Impliment pinch zoom by CSS `transform: scale(X)`
ImageLoader: Impliment panning by CSS `overflow: scroll`
ImageLoader: Larger image
MediaModal: Larger close button
MediaModal: Close the modal by swiping vertically
MediaModal: Show/hide close button and right/left navigation on tapping image
MediaModal: Change the `pointer-event` CSS prpp to get more blank space to close the modal
ImageLoader: Zoom/reset zoom on double tap
MediaModal: disable vertical swiping while horizontally swiped
ImageLoader: prevent propagating touchmove event to MediaModal
MediaModal: Adjust size and potision of buttons
ImageLoader: Adjust scroll potision on pinch zoom
* Remove "swipe to close" and "double tap to zoom" features
* remove unused prop and functions
removed `onScroll` prop and `handleScroll` func in ImageLoader
* separate zoom functionary to ZoomableImage component
adjust styling of ImageLoader
add styling for ZoomableImage
* adjust size and potision of close button of media modal
* Fix for gif video
add `onClick` prop to ExtendedVideoPlayer
specify `onClick` prop to video tag for switching nav of `MediaModal`
add `.video-modal` class to scss to separate styling for `VideoModal`
* fix styling for centering
specify height of `ZoomableImage` by pixel
clean styling for `ImageLoader`
* fix lint errors
* small fix
* fixed designated parts
* Responsively enforce 16:9 ratio on all media thumbnails in web UI
Also change video player behaviour to "contain" rather than
"cover" videos that don't fit the ratio, unlike images and GIFs,
it's expected that a video is shown fully.
* Fix spacing issues and remove floor
* Remove floor
* Add focus param to media API, center thumbnails on focus point
* Add UI for setting a focal point
* Improve focal point icon on upload item
* Use focal point in upload preview
* Add focalPoint property to ActivityPub
* Don't show focal point button for non-image attachments
- 4px rounded corners on media attachments
- Better colors/contrast for CW/media spoiler on public pages
- Fix vertical alignment of "Show more" button
- Fix layout jump when unhiding standalone media
* Fix regeneration marker not being removed after completion
* Return HTTP 206 from /api/v1/timelines/home if regeneration in progress
Prioritize RegenerationWorker by putting it into default queue
* Display loading indicator and poll home timeline while it regenerates
* Add graphic to regeneration message
* Make "not found" indicator consistent with home regeneration
* Fix accessibility of column headers
As a screen reader user new to Mastodon, I encountered the following issues with the column headers as designed:
* Jumping between them was difficult. FOr instance, passing my home timeline to reach notification settings was difficult to impossible, especially considering infinite scrolling.
* There doesn't appear to be any means for triggering the control via the keyboard. the `titleClick` handler only responds to mouse clicks.
* I didn't even realize there was a Settings toggle until I made this change.
Thanks for using ARIA in your designs. It's a huge help. But adding a `button` role doesn't add keyboard handling and other button behavior. Also, because the role was on the heading container, it obscured the controls within the container itself. This fix resolve that. It also exposes the headings as headings rather than buttons, enabling skipping columns by using screen readers' heading navigation commands.
Since I myself am blind, if this fix requires additional visual styling, I'd like help applying that so it can be merged. I'd consider it an essential accessibility fix for my and other blind users' existence on the platform. Thanks!
* Styling fixes
* Fixed overflow issue
* Add aria-autocomplete='list' in Textaria
ref: https://www.w3.org/TR/wai-aria-1.1/#aria-autocomplete
* Make detect empty string brefore assign upload description
* Change code elements in keyboard-shortcuts component to kbd
* Add validation for onMuteNotifications
* Break out nested relationship API keys
This closes#5856 by restoring the existing behavior of the `muting`
and `following` keys (returning booleans rather than truthy or false).
It adds `showing_reblogs` and `muting_notifications` keys:
* `showing_reblogs` returns true if:
1. You've requested to follow the user, with reblogs shown, or
2. You are following the user, with reblogs shown.
* `muting_notifications` returns true if you have muted the user and
their notifications as well.
* Rubocop fix
* Fix pulling reblog/mute status from relationships
I could swear this had passed tests before, but apparently not.
Works now.
* More test fixes
Really, you'd expect this to be more straightforward.
* Allow hiding of reblogs from followed users
This adds a new entry to the account menu to allow users to hide
future reblogs from a user (and then if they've done that, to show
future reblogs instead).
This does not remove or add historical reblogs from/to the user's
timeline; it only affects new statuses.
The API for this operates by sending a "reblogs" key to the follow
endpoint. If this is sent when starting a new follow, it will be
respected from the beginning of the follow relationship (even if
the follow request must be approved by the followee). If this is
sent when a follow relationship already exists, it will simply
update the existing follow relationship. As with the notification
muting, this will now return an object ({reblogs: [true|false]}) or
false for each follow relationship when requesting relationship
information for an account. This should cause few issues due to an
object being truthy in many languages, but some modifications may
need to be made in pickier languages.
Database changes: adds a show_reblogs column (default true,
non-nullable) to the follows and follow_requests tables. Because
these are non-nullable, we use the existing MigrationHelpers to
perform this change without locking those tables, although the
tables are likely to be small anyway.
Tests included.
See also <https://github.com/glitch-soc/mastodon/pull/212>.
* Rubocop fixes
* Code review changes
* Test fixes
This patchset closes#648 and resolves#3271.
* Rubocop fix
* Revert reblogs defaulting in argument, fix tests
It turns out we needed this for the same reason we needed it in muting:
if nil gets passed in somehow (most usually by an API client not passing
any value), we need to detect and handle it.
We could specify a default in the parameter and then also catch nil, but
there's no great reason to duplicate the default value.
* Add a hide_notifications column to mutes
* Add muting_notifications? and a notifications argument to mute!
* block notifications in notify_service from hard muted accounts
* Add specs for how mute! interacts with muting_notifications?
* specs testing that hide_notifications in mutes actually hides notifications
* Add support for muting notifications in MuteService
* API support for muting notifications (and specs)
* Less gross passing of notifications flag
* Break out a separate mute modal with a hide-notifications checkbox.
* Convert profile header mute to use mute modal
* Satisfy eslint.
* specs for MuteService notifications params
* add trailing newlines to files for Pork :)
* Put the label for the hide notifications checkbox in a label element.
* Add a /api/v1/mutes/details route that just returns the array of mutes.
* Define a serializer for /api/v1/mutes/details
* Add more specs for the /api/v1/mutes/details endpoint
* Expose whether a mute hides notifications in the api/v1/relationships endpoint
* Show whether muted users' notifications are muted in account lists
* Allow modifying the hide_notifications of a mute with the /api/v1/accounts/:id/mute endpoint
* make the hide/unhide notifications buttons work
* satisfy eslint
* In probably dead code, replace a dispatch of muteAccount that was skipping the modal with launching the mute modal.
* fix a missing import
* add an explanatory comment to AccountInteractions
* Refactor handling of default params for muting to make code cleaner
* minor code style fixes oops
* Fixed a typo that was breaking the account mute API endpoint
* Apply white-space: nowrap to account relationships icons
* Fix code style issues
* Remove superfluous blank line
* Rename /api/v1/mutes/details -> /api/v2/mutes
* Don't serialize "account" in MuteSerializer
Doing so is somewhat unnecessary since it's always the current user's account.
* Fix wrong variable name in api/v2/mutes
* Use Toggle in place of checkbox in the mute modal.
* Make the Toggle in the mute modal look better
* Code style changes in specs and removed an extra space
* Code review suggestions from akihikodaki
Also fixed a syntax error in tests for AccountInteractions.
* Make AddHideNotificationsToMute Concurrent
It's not clear how much this will benefit instances in practice, as the
number of mutes tends to be pretty small, but this should prevent any
blocking migrations nonetheless.
* Fix up migration things
* Remove /api/v2/mutes
* Add option to reduce motion
* Use HOC to wrap all Motion calls
* fix case-sensitive issue
* Avoid updating too frequently
* Get rid of unnecessary change to _simple_status.html.haml
* Fix#2102 - Implement hotkeys
Hotkeys on status list:
- r to reply
- m to mention author
- f to favourite
- b to boost
- enter to open status
- p to open author's profile
- up or k to move up in the list
- down or j to move down in the list
- 1-9 to focus a status in one of the columns
- n to focus the compose textarea
- alt+n to start a brand new toot
- backspace to navigate back
* Add navigational hotkeys
The key g followed by:
- s: start
- h: home
- n: notifications
- l: local timeline
- t: federated timeline
- f: favourites
- u: own profile
- p: pinned toots
- b: blocked users
- m: muted users
* Add hotkey for focusing search, make escape un-focus compose/search
* Fix focusing notifications column, fix hotkeys in compose textarea
aria-label contained body of status with content warning, which should be
hidden by default. Remove the label for the case and other cases due to
consistency.
* Fix#117 - Add ability to specify alternative text for media attachments
- POST /api/v1/media accepts `description` straight away
- PUT /api/v1/media/:id to update `description` (only for unattached ones)
- Serialized as `name` of Document object in ActivityPub
- Uploads form adjusted for better performance and description input
* Add tests
* Change undo button blend mode to difference
* Add emoji autosuggest
Some credit goes to glitch-soc/mastodon#149
* Remove server-side shortcode->unicode conversion
* Insert shortcode when suggestion is custom emoji
* Remove remnant of server-side emojis
* Update style of autosuggestions
* Fix wrong emoji filenames generated in autosuggest item
* Do not lazy load emoji picker, as that no longer works
* Fix custom emoji autosuggest
* Fix multiple "Custom" categories getting added to emoji index, only add once
* Fix JavaScript interface with long IDs
Somewhat predictably, the JS interface handled IDs as numbers, which in
JS are IEEE double-precision floats. This loses some precision when
working with numbers as large as those generated by the new ID scheme,
so we instead handle them here as strings. This is relatively simple,
and doesn't appear to have caused any problems, but should definitely
be tested more thoroughly than the built-in tests. Several days of use
appear to support this working properly.
BREAKING CHANGE:
The major(!) change here is that IDs are now returned as strings by the
REST endpoints, rather than as integers. In practice, relatively few
changes were required to make the existing JS UI work with this change,
but it will likely hit API clients pretty hard: it's an entirely
different type to consume. (The one API client I tested, Tusky, handles
this with no problems, however.)
Twitter ran into this issue when introducing Snowflake IDs, and decided
to instead introduce an `id_str` field in JSON responses. I have opted
to *not* do that, and instead force all IDs to 64-bit integers
represented by strings in one go. (I believe Twitter exacerbated their
problem by rolling out the changes three times: once for statuses, once
for DMs, and once for user IDs, as well as by leaving an integer ID
value in JSON. As they said, "If you’re using the `id` field with JSON
in a Javascript-related language, there is a very high likelihood that
the integers will be silently munged by Javascript interpreters. In most
cases, this will result in behavior such as being unable to load or
delete a specific direct message, because the ID you're sending to the
API is different than the actual identifier associated with the
message." [1]) However, given that this is a significant change for API
users, alternatives or a transition time may be appropriate.
1: https://blog.twitter.com/developer/en_us/a/2011/direct-messages-going-snowflake-on-sep-30-2011.html
* Additional fixes for stringified IDs in JSON
These should be the last two. These were identified using eslint to try
to identify any plain casts to JavaScript numbers. (Some such casts are
legitimate, but these were not.)
Adding the following to .eslintrc.yml will identify casts to numbers:
~~~
no-restricted-syntax:
- warn
- selector: UnaryExpression[operator='+'] > :not(Literal)
message: Avoid the use of unary +
- selector: CallExpression[callee.name='Number']
message: Casting with Number() may coerce string IDs to numbers
~~~
The remaining three casts appear legitimate: two casts to array indices,
one in a server to turn an environment variable into a number.
* Back out RelationshipsController Change
This was made to make a test a bit less flakey, but has nothing to
do with this branch.
* Change internal streaming payloads to stringified IDs as well
Per
https://github.com/tootsuite/mastodon/pull/5019#issuecomment-330736452
we need these changes to send deleted status IDs as strings, not
integers.
* Fix behavior while the button is invisible
e.g. pointer cursor, couldn't open contextmenu
* Avoid rendering the button to remove blank space if no more items are available or no items are rendered
