Previously, when dragging the timeline scroller, we would position it purely based on the current cursor position. That means that if you started dragging it from anywhere other than the centre, the scroller will 'jump' suddenly to centre itself on the cursor.
This commit measures the offset of your cursor when the drag starts, and maintains it throughout the drag. So for example, if you start dragging at the bottom of the scroller and drag one pixel up, the scroller will only move by 1px.
This should make the UX much smoother, especially on large topics.
When the 'loading slider' navigation indicator is enabled, and a connection is very slow, we `display: none` most of the page and display a spinner. The `still-loading` body class for this was being added in the `afterRender` step in the Ember runloop. This meant that, depending on the order they were scheduled, other `afterRender` jobs may run before it. This caused an issue with topic scroll locations because we would attempt to scroll to an element which was `display: none` at the point its position was calculated.
This commit moves the `still-loading` class manipulations to the `render` step of the runloop, which is technically more correct, and means that anything scheduled in the `afterRender` step is guaranteed to run without the `display: none` CSS.
https://meta.discourse.org/t/276305/29
This commit contains a few improvements:
* Use LinkTo instead of a button with a weird action referencing the
controller to navigate to the filtered settings for a plugin
* Add an AdminPlugin model with tracked properties and use that when
toggling the setting on/off and in the templates
* Make it so the Settings button for a plugin navigates to the correct
site setting category instead of always just going to the generic
"plugins" one if possible
Follow-up to #23199 in which we moved the "delete user" options under the relevant action menu for flagged post. This change does the same, but to queued posts.
This provides a `refresh()` function on Ember's public router service. The feature was added to Ember in v4.1.0, but this polyfill will allow us to start using it straight away under 3.28
DEV: Display fuzzy site setting search results below direct matches
When searching for site settings, in the results under the ALL category
all the fuzzy search results were showing first followed by any direct
matches. This change adjusts that so that fuzzy searches show below
direct matches.
Fuzzy results are now also sorted based on their gap calculation in
ascending order.
It is hard to catch and debug potential bugs related to live updates of
user status (though, we haven't seen many such bugs so far). We have
this `console.warn` statement that should help us to catch one class of
such bugs:
70f1cc5552/app/assets/javascripts/discourse/app/models/user.js (L1384-L1389)
But in tests, we quite often operate with stubs of users that don't have ID,
and this warning create unnecessary noise. This PR disable the warning in
the testing environment.
This could happen after you had already change the separation mode and would cause unexpected bugs.
This PR also adds more tests around using switch buttons with chat.
Reverts e2705df and re-lands #23187 and #23219.
The issue was incorrect order of execution of Rails' `assets:precompile` task in our own precompilation stack.
Co-authored-by: David Taylor <david@taylorhq.com>
Short answer -- the problem is the video thumbnail generator & uploader
code added a couple of months back in f144c64e13.
It was implemented as another Mixin which overrides `this._uppyInstance`
when uploading the video thumbnail after the initial upload is complete,
which means the composer's `this._uppyInstance` value is overridden,
and it loses all of its preprocessors & upload code.
This is generally a problem with the Mixin based architecture that I
used for the Uppy code, which we need to remove at some point and
refacotr.
The most ideal thing to do here would be to convert this video thumbnail
code into an Uppy
[postprocessor](https://uppy.io/docs/uppy/#addpostprocessorfn) plugin,
which runs on each upload after they are complete. I started looking
into this, and the main hurdle here is adding support to tracking the
progress of postprocessors to
[ExtendableUploader](cf42466dea/app/assets/javascripts/discourse/app/mixins/extendable-uploader.js)
so that is out of scope at this time.
The fix here makes it so the ComposerVideoThumbnailUppy code is no
longer a Mixin, but acts more like a normal class, a pattern which
we have used in chat. I also clean up a lot of the thumbnail uploader
code and remove some unnecessary things.
Attempted to add a system spec, but video streaming does not work
in Chrome for Testing at this time, and it is needed for the
onloadedmetadata event.
`Window`'s `resize` event was unreliable. You could shrink down the browser window so that the timeline would disappear but the progress element would not render to replace it.
This commit makes it rely on a media query listener instead so it 1. matches the css 2. fires only when that query result changes (perf win)
By default, the workbox-expiration plugin will not expire cache entries which include a `Vary` header in the response. This means that cached entries can build up until the browser storage quota is hit.
This commit introduces the `ignoreVary: true` option, so that deletion is performed correctly. This will only apply going forward, so this commit also bumps the cache version and deletes the old caches.
Ref https://github.com/GoogleChrome/workbox/issues/2206
This fixes the problem reported in
https://meta.discourse.org/t/custom-status-message-in-front-of-by-header-on-scroll/273320.
This problem can be reproduced with any tooltip created using the DTooltip
component or the createDTooltip function.
The problem happens because the trigger for tooltip on mobile is click, and for tooltip
to disappear the user has to click outside the tooltip. This is the default behavior
of tippy.js – the library we use under the hood.
Note that this PR fixes the problem in topics, but not in chat. I'm going to investigate and
address it in chat in a following PR.
To fix it for tooltips created with the createDTooltip function, I had to make a refactoring.
We had a somewhat not ideal solution there, we were leaking an implementation detail
by passing tippy instances to calling sides, so they could then destroy them. With this fix,
I would have to make it more complex, because now we need to also remove onScrool
handlers, and I would need to leak this implementation detail too. So, I firstly refactored
the current solution in 5a4af05 and then added onScroll handlers in fb4aabe.
When refactoring this, I was running locally some temporarily skipped flaky tests. Turned out
they got a bit outdated, so I fixed them. Note that I'm not unskipping them in this commit,
we'll address them separately later.
This commit adds some system specs to test uploads with
direct to S3 single and multipart uploads via uppy. This
is done with minio as a local S3 replacement. We are doing
this to catch regressions when uppy dependencies need to
be upgraded or we change uppy upload code, since before
this there was no way to know outside manual testing whether
these changes would cause regressions.
Minio's server lifecycle and the installed binaries are managed
by the https://github.com/discourse/minio_runner gem, though the
binaries are already installed on the discourse_test image we run
GitHub CI from.
These tests will only run in CI unless you specifically use the
CI=1 or RUN_S3_SYSTEM_SPECS=1 env vars.
For a history of experimentation here see https://github.com/discourse/discourse/pull/22381
Related PRs:
* https://github.com/discourse/minio_runner/pull/1
* https://github.com/discourse/minio_runner/pull/2
* https://github.com/discourse/minio_runner/pull/3
This PR changes how we track which lists are available for a topic and how we decide which is the active one. The new approach centralizes everything in the service, and exposes functions for adding/removing a list, which each calls via `did-insert/will-destroy` modifiers.
It makes it much easier to track and update state when navigated to another topic or PM, ensuring things get updated correctly.
Separate mobile templates are a pattern we're moving away from. They are not supported by Ember, and make things more difficult to develop/test. The differences between the mobile and desktop templates for `discovery/topics` are very minimal, so they can be easily integrated.
The only feature missing from the main template was the new 'list header controls' UI. This commit introduces that to the main template inside an `mobileView` conditional.
Key changes in behavior, many of which could be considered bug fixes, are:
- Mobile will now include 'redirected reason'
- Mobile will now include shared drafts
- Mobile will now include before-topic-list and after-topic-list Plugin Outlets
- Mobile will now have a `<div class="show-more">` wrapper around the 'new or updated' UI, to match desktop. This does not seem to cause any visual change.
Mobile-specific template overrides of `discovery/topics` will continue to function as before - this should not be a breaking change for any themes/plugins.
Mobile-specific templates for the topic list and topic-list-item remain in place.
Sometimes the fuzzy search would return too many site setting results
making it hard to find what you are searching for. This change still
allows for fuzzy searching but tightens up the criteria for being a
fuzzy match.
One example is searching for 'cheer', a term associated with a plugin,
previously returned ~55 search results. With this change it will return
~13 (Actual numbers depend on how many plugins your instance has).
Another example is searching for 'digest'. Previously returned ~37
results and now will return ~14.
Follow up to: e63e193a0a
See also: https://meta.discourse.org/t/276013
