User status updates come from the server in a map where keys are user IDs.
If user.trackStatus() is called for a user model without an ID, the model
cannot identify its status updates and silently misses them. It's quite hard to
notice that a user rendered in the UI doesn't receive live status updates.
Also, it's not immediately obvious what's the reason of the problem.
A warning will be very helpful here.
Named outlets are deprecated and will be removed in Ember 4.x.
Backwards-compatibility shims are introduced so that plugin overrides to `controller:composer` are ported to `service:composer`.
After removing `TextareaTextManipulation` from `ChatComposer` and using `TextareaInteractor` as a proxy, one function has been forgotten: `paste(event)` which is not available in glimmer components anymore, and even less avaiable now that the mixin is not tied to a component anymore but a real DOM node. As a solution we now add a manual paste event listener which will call `paste(event)`.
This pull request is a full overhaul of the chat-composer and contains various improvements to the thread panel. They have been grouped in the same PR as lots of improvements/fixes to the thread panel needed an improved composer. This is meant as a first step.
### New features included in this PR
- A resizable side panel
- A clear dropzone area for uploads
- A simplified design for image uploads, this is only a first step towards more redesign of this area in the future
### Notable fixes in this PR
- Correct placeholder in thread panel
- Allows to edit the last message of a thread with arrow up
- Correctly focus composer when replying to a message
- The reply indicator is added instantly in the channel when starting a thread
- Prevents a large variety of bug where the composer could bug and prevent sending message or would clear your input while it has content
### Technical notes
To achieve this PR, three important changes have been made:
- `<ChatComposer>` has been fully rewritten and is now a glimmer component
- The chat composer now takes a `ChatMessage` as input which can directly be used in other operations, it simplifies a lot of logic as we are always working a with a `ChatMessage`
- `TextareaInteractor` has been created to wrap the existing `TextareaTextManipulation` mixin, it will make future migrations easier and allow us to have a less polluted `<ChatComposer>`
Note ".chat-live-pane" has been renamed ".chat-channel"
Design for upload dropzone is from @chapoi
Due to the order we were parsing markdown, bbcode [url] elements were not
handled properly.
`[url]https://example.com/path[/url]` was not currectly parsing cause
linkify was detecting the url as: `https://example.com/path[/url]` which is
legit.
To resolve this I swapped url to use a replace rule, and instead re-parsed
the internal payload and injected the tokens in.
This fix is complex cause we support stuff like
`[url][b]test.com[/b][/url]`
So we need to parse the content inside url `[b]test.com[/b]`
* FIX: Blank video thumbnails
On some mobile and possibly other browsers, the automatic video
thumbnail generation would create blank or all white images.
This commit addresses several different issues that was preventing image
generation from working correctly on mobile.
* fix typo
The updated user menu is the default for new sites, and will soon be enabled on older sites. This commit removes the 'EXPERIMENTAL' warning from the new `registerUserMenuTab` API, and adds a note to the `addUserMenuGlyph` documentation.
Followup to 17ba00c395.
Fix for https://meta.discourse.org/t/-/261917
This fixes a usability issue where the user couldn't switch to the user
menu when the search menu was visible and the text in the input was
selected.
Explanation: The `click` event is triggered both when clicking and when
selecting some text and clicking. This means that when selecting text in
the search input, at the end of the selection event, a click event was
triggered. And if that click event happened to be outside of the search
menu, then the menu would be dismissed.
Previously, we fixed this by checked if a current text selection was
present. But that results in a small side-effect of not switching to
other menus. This PR switches to setting a flag during `mouseDown` and
then using that flag when evaluating whether to trigger clickOutside or
not.
It's backward compatible so still supports our 3.28 ember-source.
The visible change is finally getting rid of this message:
```
WARNING: Node v18.12.0 is not tested against Ember CLI on your platform. We recommend that you use the most-recent "Active LTS" version of Node.js. See https://git.io/v7S5n for details.
```
---
`@ember/string` dependency is added for future compatibility. See: https://github.com/ember-cli/ember-cli/pull/10125
---
`tests/helpers/index.js` is unused for now, but is a nice pattern. We could move some of our test setup into local `setupApplicationTest/setupRenderingTest/setupTest` helpers.
Co-authored-by: David Taylor <david@taylorhq.com>
All supported browsers use `transitionend` event now, so this code is not necessary and makes it difficult to use that event in tests (you'd have to trigger all variants to cover the bases)
That function was used only in core (no hits in all-the*) in two places, so I think it's rather safe to just trash it without deprecating it first.
(History Corner – this helper was originally added in the initial commit of Discourse! 1839614bcc/app/assets/javascripts/discourse/components/transition_helper.js.coffee)
Following a change in e9f7262813 which prevents the notification level to be returned from the update endpoint, the model couldn't update itself. This commit makes the update manually and adds a test to prevent future regressions.
Note we could also change the backend endpoint, but this should work correctly with minimum risk.
As a single example, if a `<kbd>` tag is wrapped by a `<a>` link, it doesn't inherit the link color:
`[<kbd>❓ **Support**</kbd>](https://meta.discourse.org)`
It's because the `<kbd>` tag has a `color: var(--primary);` CSS rule which seems superfluous.
If we disable it, the `<kbd>` tag inherits all the normal colors (including the link color 👌).
The direct `<kbd>` parent that assigns the text color is `<html>` (can't go higher!) which has an identical `color: var(--primary);`.
WCAG palettes don't seem to assign specific colors in this context.
It seems fairly safe to remove `color: var(--primary);` from `<kbd>` so it won't interfere anymore with its content.
