This PR makes adjusted composer height persistent for a user. After dragging to change the composer height, the updated height will be stored in localStorage and will be restored when opening the composer again.
We subscribe to a couple of MessageBus channels when the review-index route is entered, but we should unsubscribe when exiting the route otherwise callbacks would leak every time the review-index is entered and that might cause subtle and weird bugs or errors.
When there are pending reviewables, the review section link is displayed
in the main section. When there are no pending reviewables, the review
section link is displayed under the more links drawer.
Internal ref: /t/74210
* FEATURE: add composer warning when user haven't been seen in a long time
When a user creates a PM and adds a recipient that hasn't been seen in a
long time then we'll now show a warning in composer indicating that the
user hasn't been seen in a long time.
- in group activity, allows avatars to be selectable by tabbing or screen readers
- in user activity > drafts, fixes a bug where for draft replies, the wrong avatar was being shown in the user card
- in both group and user activity, fixes the order of focusable items
* FIX: Better virtual keyboard detect on Android
Firefox has a bug where *sometimes* the visualViewport.height won't be
updated when the keyboard pops up until you scroll, making our composer
stay hidden behind the keyboard. This commit uses both window.innerHeight
and window.visualViewport.height using the minimum of both to check for
height changes.
For Chrome/Edge we feature detect the new VirtualKeyboard API and
opt-into it when the composer opens and use it to detect if a keyboard
is being draw. Opting into the API changes how the viewport is
calculated so we have to also change how the full height composer is
calculated. To minimize breakage we opt-out when the composer component
is destroyed.
This commit also moves the `--composer-ipad-padding` to only happen on
iPads.
Bug report at https://meta.discourse.org/t/-/228382
Although showPopover continues to toggle the popover (showing if hidden / hiding if shown), hidePopover now will only hide the popover. Furthermore, isPopoverShown has been introduced to provide insight into whether the popover is currently shown or not, and therefore whether it should be hidden or shown.
Also, the showPopover / hidePopover test has been refined to override `trigger` and `hideOnClick` settings to allow for full imperative control of showing / hiding the popover.
This will replace `enable_personal_messages` and
`min_trust_to_send_messages`, this commit introduces
the setting `personal_message_enabled_groups`
and uses it in all places that `enable_personal_messages`
and `min_trust_to_send_messages` currently apply.
A migration is included to set `personal_message_enabled_groups`
based on the following rules:
* If `enable_personal_messages` was false, then set
`personal_message_enabled_groups` to `3`, which is
the staff auto group
* If `min_trust_to_send_messages` is not default (1)
and the above condition is false, then set the
`personal_message_enabled_groups` setting to
the appropriate auto group based on the trust level
* Otherwise just set `personal_message_enabled_groups` to
11 which is the TL1 auto group
After follow-up PRs to plugins using these old settings, we will be
able to drop the old settings from core, in the meantime I've added
DEPRECATED notices to their descriptions and added them
to the deprecated site settings list.
This commit also introduces a `_map` shortcut method definition
for all `group_list` site settings, e.g. `SiteSetting.personal_message_enabled_groups`
also has `SiteSetting.personal_message_enabled_groups_map` available,
which automatically splits the setting by `|` and converts it into
an array of integers.
When `allow_uncategorized_topics` is set to `false`, we do not want to
show the uncategorized in sidebar by default.
This commit updates a couple of places in the code related to sidebar
which was incorrectly using `suppress_uncategorized_badge` site setting
which is mainly used for hiding the category badge for uncategorized
category and should not be used to determine if uncategorized categories
should be allowed or not.
This PR makes some updates to the prior keyboard accessibility commit (eb98746):
- Makes `tabindex` attribute only appear on emoji markup in the emoji picker.
- After pressing the Esc key, focus returns to the <textarea/> input (composer editor or chat input)
* DEV: Add test case for syntax highlight of complex HTML
The commit 685e0da upgrade HighlightJS to version 11, which deprecates
syntax highlight of complex HTML elements. See https://github.com/highlightjs/highlight.js/issues/2889
This brought a regression of syntax highlighting of GitHub oneboxes,
which was fixed in 09cec7d. This commit adds a test case to prevent
future regressions like this one.
* fix test and warning
* DEV: Make emoji elements focusable
Since emoji elements are of type `<img>` it requires a `tablindex="0"` in order to be focusable.
* WIP: Handle emoji focus/selection via arrow keys
Near completion, however, need a few fixes/improvements and overall code cleanup
* WIP: Testing
* DEV: Fixes and cleanup
* DEV: Follow conventions
* DEV: Improve up/down traversal when recents present
* DEV: Emoji markup in tests should include `tabindex`
* DEV: Add `tabindex` to topic tests
* DEV: Variable name as `searchInput` instead of `searchBar`
* DEV: Use appropriate method name (`_setNumEmojiPerRow`)
* DEV: Add comments and avoid nested if
* WIP: Adding test
* Fix first test
* DEV: Add assertions for arrow keys and escape key
* Some fixes for up/down navigation
This does not fix everything, when going from one section to another,
there are issues
* Fix a small regression
* FIX: Ability to focus on search results
Fixes regression
* Refactor calculating next up/down emoji
* Debugging test failure
* Skip stubborn CI test, add others
Co-authored-by: Penar Musaraj <pmusaraj@gmail.com>
This isn't a security bug, because only admins can create user fields
and we have to trust admins, because they can change themes, which are
shown site-wide and can contain unrestricted JS.
Both versions are used with `--headless`, so labelling one "Firefox" and the other "Firefox Headless" doesn't really make sense. Evergreen / ESR are better descriptions.
Using the owner of `site` is not perfectly reliable, especially given that `site` is stubbed in tests. Instead, we can fetch the owner of the `context` object itself.
Also, Ember sets the owner of an EmberObject based on the first parameter to `create`. This is preferable to a separate `setOwner` call because it means the owner is available during initialization.
Unfortunately we don't have any way to compile raw templates inline during tests, so testing this behavior in core is very difficult. Given that we aim to remove the raw handlebars system in the not-too-distant future, it doesn't make sense to invest lots of time on tooling here. Regressions of this behavior will be detected by theme CI tests [like this](https://github.com/discourse/discourse-topic-thumbnails/pull/21).