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
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!
* 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.
Eugen Rochko