* 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
* Redesign video player
* Use new video player on static public pages too
* Use media gallery component on static public pages too
* Pause video when hiding it
* Full-screen sizing on WebKit
* Add aria labels to video player buttons
* Display link card on public status page
* Fix fullscreen from modal sizing issue
* Remove contain: strict property to fix fullscreen from columns
Resolved:
* Lot of redundant renders while mouse moving
* Scroll jumping when timeline loaded
* Scroll position isn't kept when statuses below the scrollTop was deleted then new status arrived
Unresolved:
* Scroll position isn't kept when statuses over the scrollTop was deleted then new status arrived
-> It needs to know which statuses are over the scrollTop
* New status indicator should be active when new statuses arrived while mouse moved recently
-> It needs a) update indicator in ScrollableList, or b) set scrollTop status while mouse moving
* Refactored Avatar and AvatarOverlay (DRY) to have 'account' as prop.
Also removed animate attribute from compose navigation bar, which should
have never been there. Added test for avatar overlay.
* fix broken tests
* god dammit another bug in tests! travis please let this pass
* formatting in avatar overlay
The feature to pin column could hide the rightmost column, which is
specified with children property of ColumnsArea.
The user is likely to see the column when the property changed, so scroll
the area in such cases.
* fix(status_action_bar): Use aria-pressed for reblog and favourite button
* fix(column_back_button): Keyboard accessible
* fix(status_content): Make focusable and accessible
* fix(dropdown_menu): Use aria-expanded instead of aria-pressed
* fix(emoji_picker_dropdown): Use aria-expanded instead of aria-hidden
* feat(icon_button): Add aria-expanded
* fix(privacy_dropdown): Use aria-expanded instead of aria-hidden
