This is actually making things more sluggish than necessary. If any perf issue happen out of this they should be handled in the consequences of the resizing, not the resizing itself.
Currently navigating a long topic and then opening chat would cause the view to be scrolled to the bottom. Using `scrollTop` here ensures we correctly scroll to top.
This had been incorrectly moved into `deactivate` during another change.
* FIX: increases resize observer throttle delay
25ms is not necessary and was sometimes causing jankyness.
* FIX: removes ios momentum fix delay
Instead of a 50ms, simply use next+schedule("afterRender") to attempt to have the shortest delay possible.
* FIX: backdrop event propagation
Prevents backdrop touch to propagate to underlying channel/thread.
* UX: adds is-active class to container of active message
This change allows to keep the background on the active message while the actions menu is displayed.
* FIX: prevents skip-link to be selected on press
* UX: allows to close actions menu instantly
The backdrop should always receive events, we don't need to wait for the menu to be fully displayed.
* UI: adds spacing between last message and composer
* UI: makes backdrop less dark
* FIX: makes events passive on long-press modifier
Previously workbox JS was vendored into our git repository, and would be loaded from the `public/javascripts` directory with a 1 day cache lifetime. The main aim of this commit is to add 'cachebuster' to the workbox URL so that the cache lifetime can be increased.
- Remove vendored copies of workbox.
- Use ember-cli/broccoli to collect workbox files from node_modules into assets/workbox-{digest}
- Add assets to sprockets manifest so that they're collected from the ember-cli output directory (and uploaded to s3 when configured)
Some of the sprockets-related changes in this commit are not ideal, but we hope to remove sprockets in the not-too-distant future.
We have been struggling a lot on this lately as it's almost impossible to write a decent test for this.
The important things which need to happen:
- fetch the unread/mention state and last message bus channel ids of each chat channels
- stop all subscriptions
- restart global chat subscriptions
- update channels with new state and ensure the message bus ids are updated
- restart subscriptions of each chat channel
As a followup we need to start implementing a standard way to query for a resource state. Something similar to: `/channels/tracking` and `/channels/:id/tracking`
Each of these endpoints would return a state similar to:
```json
{
tracking: { ... },
message_bus_ids: { ... }
}
Removing a reaction could start a long press at the same time and put the screen in a stuck state.
This commit ensures we give an opportunity to the reaction to capture the event first and not propagate further.
These spec are flaky only in CI, not locally and not in GitHub actions.
The previous attempt was in 44eabde, but actually the failure happens
a bit earlier. This is another attempt to fix these specs. Quite a lot of
async logic is happening in emulateAutocomplete(), a call to settled()
in the end should help make it more reliable.
At the moment, PMs to groups with default notification level set to
`watching_first_post` do not generate "emailable" notifications. This happens
because, topic user notification level which is indirectly derived
from the group's default notification level is set to `tracking` if the
group's notification level happens to be `watching_first_post`.
This leads to a `group_message_summary` notification being created
instead of a `private_message` notification which results in no email
alerts being sent when a topic is created.
As this `watching_first_post` --> `tracking` switcheroo appears to be
intentional instead being a bug, this change extends `PostAlerter`'s
`notify_pm_users` method to create a `private_message` notification for
first posts created in a `watching_first_post` group even if the topic
user notification level is set to `tracking`
This commit attempts to have a bullet proof solution to the following case:
- long press on message (finger is still pressed)
- menu appears
- a button is now at finger location
- user releases finger
- a click is triggered on the button
Classic event canceling solution won't work here for performance reasons as we need the event to be passive in a scroll list.
In some cases, plugins may want to hide some of these actions
at all times, overriding the rules for canX with hiding these
buttons. To achieve this, a plugin can call the API
`removeChatComposerSecondaryButtons` and pass the list of button
IDs that should be removed as argument, like the example below:
```
withPluginApi("1.2.0", (api) => {
api.removeChatComposerSecondaryActions("copyLink", "select");
});
```
---------
Co-authored-by: Martin Brennan <martin@discourse.org>
These specs were skipped in d6d5eae1. They sometimes failed, and only on CI,
not in GitHub Actions.
I wasn't able to reproduce failures locally, but I expect clicking the send button
in chat composer should be more reliable than emulating pressing <kbd>Enter</kbd>.
When editing a message, we call `message.cook()` in the beginning of
`#sendEditMessage` methods, but when sending a new message,
the call to `message.cook()` is hidden in the `stageMessage` method.
We can just call `message.cook()` before sending the message, no matter
whether this is a new message or an edited message.
No test as this is very much a hack while lightbox is being revamped. We currently have no good/easy way AFAIK to stop event propagation on escape in magnificpopup.
This behavior has been possible for a long time and has been made more in recent commits. On PWA iOS when release the touch after the mobile actions menu has been shown, if the finger was over one of the buttons of the menu, it would trigger a click.
This commit should now correctly trap and cancel events.
The following case would create the perception of a broken back button on desktop:
- open discourse on home page
- click chat button in header
- hit back button
- observes that we are still on the channel didn't navigate to homepage as we would have expected
The back button is actually working but it's in a loop. We were doing a `transitionTo` after finding the ideal channel to show, so the browser history would look something like this:
- home
- chat index
- channel page
When hitting back, we would go to chat index which would run the same logic and transition us to channel page.
This change will use `replaceWith` to replace the chat index step by the channel step, this way our history will now look like this:
- home
- channel page
Hitting back will now correctly bring us to home.
This commit attempts to refactor our long press logic to make it more resilient and precise.
With this improvement two very UX/UI changes have been made:
- scale animation on long press
- prevents click on reaction to propagate to the message which would cause the active state of the message to trigger
This fixes an issue where a user could send an empty
string as a chat message .e.g ' ' and the message would
be posted. We don't want this, we need to strip the message
first before validating for length etc.
What does this change do?
This change is a continuation of
2191b879c6 and adds an input filter to the
edit sidebar categories modal which the user can use to filter through
the list of categories by the category's name.
Note that if a child category is being shown, all of its ancestors will
be shown even if the names of the ancestors do not match the given
filter. This is to ensure that we continue to display the hierarchy of a
child category even if the parent category does not match the filter.
Followup to e6c6c342d9,
we missed one part of this refactor which was to give
the correct composer element reference to ChatComposerUploads.
Without this the pasteEventListener for uploads was not
bound so uploading via paste did not work.
I tried to test this, and though I can write binary/text to
the clipboard and paste it into the composer, it does not
seem to be possible to end up with a paste event that
has clipboardData.files filled in, which is what is used
for the uploads. I think this is a restriction of JS
generally, and there doesn't seem to be a way to work around
it, so unfortunately we have to have no test for this still.
Why does this commit do?
This commit adds support for sub-subcategories in the new edit sidebar
categories modal added in fc296b9a81. Note
that sub-subcategories are enabled when `max_category_nesting` is set to
`3`.
