There are flaky system tests that have been exhausting the 10 seconds
default max wait time which we have set previously on CI. However, I
have yet to be able to figure out why and lack the tools to be able to
figure out why. The hope here is that the upcoming playwright driver
will provide us with better tooling to debug such problems.
I've attempted to use `Capybara::Session#using_wait_time` by there is
some race condition going on where the session's default max wait time
is sometimes not set properly. I can't figure out why and have spent too
much time trying to figure out why. Instead, I will just bump up the
`default_max_wait_time` to `20`. This may the build take longer when
there are test failures but it is a trade-off we will make right now.
This introduces functionality to chat transcripts. If
you select _only_ a thread's OP and press the Copy button,
we will now copy the OP plus all of the thread's replies
into the transcript.
This is being done to make it easier to copy all the context
of a thread easily. The old way of selecting only some messages
inside a thread still works too.
This commit also unskips and refactors some transcript specs.
This aligns closer to how we are passing data through to such helper
classes (for example, the UserFieldsHelperClass
https://github.com/discourse/discourse/pull/31670) and reduces coupling
with the component itself.
Fixing hashtag text glued to the icon, and updated some related properties to using better units.
---------
Co-authored-by: Martin Brennan <martin@discourse.org>
We now have 3 search UX variations:
* Header search
* Welcome banner search
* Icon search
And within each of these there is a `<SearchMenu />`
component with an input that needs to be focused based
on either Ctrl+F or `/` shortcuts. This commit makes
sure that each has a unique ID, and moves the functionality
of determining the "current" input ID and focusing the
input to the search service.
This fixes issues like where pressing Ctrl+F twice on
the header search would not reveal the regular browser
search.
Elements with position: fixed are taken out of the rendering context, so we can't easily make the banner the width of the main container using CSS. We tried a CSS hack, but that doesn't scale to larger screens, and probably breaks in some themes.
This is a simple JavaScript implementation that matches the width of the main container.
This builds onto #32013 in two major ways:
- Unsaved changes are now persisted when you browse categories inside "All site settings".
- If you're about to navigate away (and lose edits) you will be prompted if you want to save or discard changes. (This applies to individual category site setting pages as well.
This commit adds an indicator of the shortcut for admin search to the
full page version of the search.
In addition, this commit does extensive refactoring of
`AdminSearchDataSource` and
adds many more tests for it to account for all the variations of
label/url formatting.
This change forces consistency around code font in Discourse once the
new
rich-editor is enabled
- This means all code blocks in Discourse will render with this font
- Additionally the markdown mode composer will render with this font
Additionally we make 3 small adjustments:
1. We disable ligatures which conflict with typographer
2. We add support for custom ligature settings
3. We adjust down font size, cause 14px ends up matching visually with a
16px non monospace font, this change is already in place previously on
posts
Example:
Since 3e4eac0fed05daedcdea50d6275e143469d55eda, the daily
`Jobs::BadgeGrant` scheduled job enqueues one `Jobs::BackfillBadge`
job per enabled badge. This can become problematic on large sites that
have alot of enabled badges as the long running queries executed by each
`Jobs::BackfillBadge` job may end up exhausting all available
database connections in a short span of time. To combat this, we are
limiting the `cluster_concurrency` of the `Jobs::BackfillBadge` job to
`1`.
The system test relies on a MessageBus message being published and
received by the client. As we currently don't have a reliable way to
ensure that we run an assertion after the client has received all
MessageBus messages, we will just double the timeout for now.
