This reverts commit 7c51dd43cd86c6af2156d7124983452577ecd532.
This isn't strictly required for this pretty-text change, so we'll land it in a separate PR
Historically, we iterated through requirejs.entries and used `.unshift()` to build the list of features. I'm not sure why that was done, but the server-side PrettyText specs show that we've come to depend on that ordering.
With Embroider, we can rely on async `import()` to do the splitting
for us.
This commit extracts from `pretty-text` all the parts that are
meant to be loaded async into a new `discourse-markdown-it` package
that is also a V2 addon (meaning that all files are presumed unused
until they are imported, aka "static").
Mostly I tried to keep the very discourse specific stuff (accessing
site settings and loading plugin features) inside discourse proper,
while the new package aims to have some resembalance of a general
purpose library, a MarkdownIt++ if you will. It is far from perfect
because of how all the "options" stuff work but I think it's a good
start for more refactorings (clearing up the interfaces) to happen
later.
With this, pretty-text and app/lib/text are mostly a kitchen sink
of loosely related text processing utilities.
After the refactor, a lot more code related to setting up the
engine are now loaded lazily, which should be a pretty nice win. I
also noticed that we are currently pulling in the `xss` library at
initial load to power the "sanitize" stuff, but I suspect with a
similar refactoring effort those usages can be removed too. (See
also #23790).
This PR does not attempt to fix the sanitize issue, but I think it
sets things up on the right trajectory for that to happen later.
- Remove the wildcard crawler. This was already excluding almost all file types, but the exclude list was missing '.gjs' which meant those files were unnecessarily being hoisted into the `public/` directory during precompile
- Automatically include all ember-cli-generated assets without needing them to be listed. The main motivation for this change is to allow us to start using async imports via Embroider/Webpack. The filenames for those new async bundles will not be known in advance.
- Skips sprockets fingerprinting on Embroider/Webpack chunk JS files. Their filenames already include a fingerprint, and having sprockets change the filenames will cause problems for the async import feature (where filenames are included deep inside js bundles)
This commit also updates our ember-cli build so that it skips building plugin tests in the production environment. This should provide a slight build speed improvement.
Previously, focus wasn't being applied correctly on dialogs using named
components. This was because the A11YDialog was being invoked before
the component was completely rendered.
The long-term plan is to move away from A11YDialog doing the rendering
here, but for now this should do.
These have been deprecated for some time, and the vast majority of themes/plugins have already removed their use. The prototype extensions were unexpectedly disabled as a side effect of 895036bd7a057f2430c5c917040319577fcf6b95 (more details in https://github.com/discourse/discourse/pull/24101).
Given that restoring the functionality now involves significant complexity, and would only be delaying the inevitable removal in a matter of months, we've decided to keep them disabled. This commit explicitly sets the flag in the ember environment config to make things clearer.
In the past we would build the stack of Omniauth providers at boot, which meant that plugins had to register any authenticators in the root of their plugin.rb (i.e. not in an `after_initialize` block). This could be frustrating because many features are not available that early in boot (e.g. Zeitwerk autoloading).
Now that we build the omniauth strategy stack 'just in time', it is safe for plugins to register their auth methods in an `after_initialize` block. This commit relaxes the old restrictions so that plugin authors have the option to move things around.
We already do this check inside `selectionChanged` and this was preventing us to correctly set `isSelecting` to true. This was causing issues when starting your selection from outside cooked.
Applies to passkeys, visible in a dev environment when using a non-standard
host. The error modal should only be shown when invoking the passkey
login button.
Previously, we would build the stack of omniauth authenticators once on boot. That meant that all strategies had to be included, even if they were disabled. We then used the `before_request_phase` to ensure disabled strategies could not be used. This works well, but it means that omniauth is often doing unnecessary work running logic in disabled strategies.
This commit refactors things so that we build the stack of strategies on each request. That means we only need to include the enabled strategies in the stack - disabled strategies are totally ignored. Building the stack on-demand like this does add some overhead to auth requests, but on the majority of sites that will be significantly outweighed by the fact we're now skipping logic for disabled authenticators.
As well as the slight performance improvement, this new approach means that:
- Broken (i.e. exception-raising) strategies cannot cause issues on a site if they're disabled
- `other_phase` of disabled strategies will never appear in the backtrace of other authentication errors
The main change made is to use `pointerdown` and `touchstart` for detecting click outside in `FloatKit`, the problem of using `click` is that it will trigger on `mouseup` which is not working well with `FloatKit` shown using `mousedown` (when we change selection with the `mousedown` for example) as the release will be interpreted as a click outside and close the menu. To solve this issue the previous code in `post-text-selection` was going through various hacks for detecting state of mouse which are not always very reliable.
The second fix is to exit earlier when selection didn't change.
This has been tested on chrome/firefox and safari (mobile) and seems to work reliably.
<!-- NOTE: All pull requests should have tests (rspec in Ruby, qunit in JavaScript). If your code does not include test coverage, please include an explanation of why it was omitted. -->
1. Removes accidental bold from `text` and `multiselect` labels/placeholders
2. Adds the animated label/placeholder combo to `multiselect`
3. Makes the `multiselect` placeholder lighter to match other fields
4. Makes the `dropdown` values darker to match other fields
5. Removes the extra 5px spacing before `confirmation` fields
`@ember/jquery` was necessary to automate the `app.import()` but
that is no longer necessary with `ember-auto-import`. A secondary
thing it does is bringing back the `this.$` feature, but with a
deprecation. It is my understanding that the deprecation has long
be fully absorbed into both core and plugins so we shouldn't need
this package anymore.
No plugins or themes rely on anonymous_posting_min_trust_level so we
can just switch straight over to anonymous_posting_allowed_groups
This also adds an AUTO_GROUPS const which can be imported in JS
tests which is analogous to the one defined in group.rb. This can be used
to set the current user's groups where JS tests call for checking these groups
against site settings.
Finally a AtLeastOneGroupValidator validator is added for group_list site
settings which ensures that at least one group is always selected, since if
you want to allow all users to use a feature in this way you can just use
the everyone group.
Back in c31772879bc9df51b71f75edc529bfed878d65d1 we introduced
SiteSetting.composer_ios_media_optimisation_image_enabled and
disabled media optimization on safari iOS because of performance
issues when rendering to canvas, and OffscreenCanvas support
was not yet available.
Safari now supports OffscreenCanvas, so now we can give this
another go, and also use OffscreenCanvas everywhere it is supported.
Using Wizard.exclude_steps applies to all sites in a multisite cluster.
In order to exclude steps for individual sites at run-time, a new
instance method `remove_step` is being added.
We were incorrectly generating URLs with message id even when it was not provided, resulting in a route ending with "undefined", which was causing an error.
This commit also uses this opportunity to:
- move `invite_users` into a proper controller inside the API namespace
- refactors the code into a service: `Chat::InviteUsersToChannel`
