Meta topic: https://meta.discourse.org/t/mention-suggestion-list-box-in-the-rtl-website-in-wrong-place/266763?u=osama.
Our autocomplete box doesn't currently take into account the user's locale and places itself off-screen when using an RTL locale. This commit changes the placement logic for the autocomplete box when an RTL locale is used to make sure that:
1. the autocomplete box's right side is near and to the left of the caret
2. the autocomplete box doesn't go beyond the composer's left side.
When a topic already has multiple synonym tags of a target tag, if we try to update the "`tag_id`" column to target tag id then it will raise a unique violation error since there are multiple synonyms present in the topic. So before doing that action, we must delete the problematic tags so the topic has only one synonym tag to update.
This is not an issue when the topic has a target tag already along with synonyms.
`DiscourseIpInfo` expects zeitwerk auto-loading to be available, so we need to ensure the rake task loads the full rails environment. Normally we run this task as part of assets:precompile, so the app is already initialized. This commit only affects the case where the maxmind task is run directly.
Few weeks ago we implemented `onPresenceChangeCallback` to re-sync chat channels state when going back to a long time inactive tab. This codepath however contained a bug as we were reseting all subscriptions but only restarting global subscriptions and not per channel subscriptions.
This commit should correctly ensure we correctly do so. It's sadly very hard to test time related changes in system specs.
Co-authored-by: Martin Brennan <mjrbrennan@gmail.com>
What is the problem?
We were calling out to methods that calls `has_css?` or `has_selector?`
which returns a boolean. Since we are not using the return value, it
means the methods can be deemed unnecessary. However, we do want those
checks and this commit adds the necessarily assertions to make use of
the return values.
When a user type a message with mentions, the autocomplete popup
may suggest users or groups. We were adding all these object to
the `currentMessage.mentionedUsers` collection, while we should
have been adding only users. A group added to that collection led to
the error later when trying to update user status on mentions.
Test were sometimes failing with similar error to the following:
```
1) UsernameChanger#override when unicode_usernames is off overrides the username if a new name has different case
Failure/Error:
protect { v8.eval(<<~JS) }
__paths = #{paths_json};
__utils.avatarImg({size: #{size.inspect}, avatarTemplate: #{avatar_template.inspect}}, __getURL);
JS
MiniRacer::RuntimeError:
ReferenceError: __optInput is not defined
# JavaScript at exports.helperContext (<anonymous>:21:17)
# JavaScript at getRawAvatarSize (<anonymous>:108:49)
# JavaScript at avatarUrl (<anonymous>:102:21)
# JavaScript at Object.avatarImg (<anonymous>:129:15)
# JavaScript at <anonymous>:2:9
# ./lib/pretty_text.rb:259:in `block in avatar_img'
# ./lib/pretty_text.rb:661:in `block in protect'
# ./lib/pretty_text.rb:661:in `synchronize'
# ./lib/pretty_text.rb:661:in `protect'
# ./lib/pretty_text.rb:259:in `avatar_img'
# ./app/jobs/regular/update_username.rb:14:in `execute'
```
This should not be needed as it should already have been initialised but that should stop the flakey-ness for now while being a safe change.
This will make it simpler to work with this code. This also can make this code more stable and increase stability of our test suite.
Cooked message now will be available immediately after cooking, it wasn't the case before:
await message.cook();
const cooked = message.cooked;
This also removes a call to `message.cook()` from message fabricator. Alternatively we may leave the call there and make the fabricator function async, but I fill it's better this way. If someone needs to test something related to cooked message, they can either pass cooked text to fabricator:
message = fabricators.message({ cooked: "<p>cooked</p>" });
or call `message.cook()` after fabrication:
message = fabricators.message({ message: "raw message" });
await message.cook()
It seems like the overhead of GPU acceleration is not worth it and is
slowing down our system tests. Locally the following command completes
in `2 minutes 8.6 seconds` with GPU disabled as compared to `2 minutes 45.4 seconds` with GPU enabled.
This reverts commit ddf4ecba04.
Causing a flaky test to appear:
```
main $ LOAD_PLUGINS=1 rspec plugins/chat/spec/system/chat/composer/shortcuts/channel_spec.rb
Randomized with seed 17765
.....F..
Failures:
1) Chat | composer | shortcuts | channel when using ArrowUp when last message is staged does not edit a message
Failure/Error: channel_page.send_message
expected `#<PageObjects::Components::Chat::Messages:0x00007fe823ac1710 @context=".chat-channel">.has_message?({:persisted=>true, :text=>"2"})` to be truthy, got false
[Screenshot Image]: /home/tgxworld/work/discourse/tmp/capybara/failures_r_spec_example_groups_chat_composer_shortcuts_channel_when_using_arrow_up_when_last_message_is_staged_does_not_edit_a_message_148.png
```
```
1) TopicsFilter#filter_from_query_string ordering topics filter when ordering topics by creation date when query string is `order:created-invalid` should return topics ordered by the default order
Failure/Error:
expect(
TopicsFilter
.new(guardian: Guardian.new)
.filter_from_query_string("order:#{order}-invalid")
.pluck(:id),
).to eq(Topic.all.order(:id).pluck(:id))
expected: [484, 485, 486]
got: [486, 484, 485]
```
What is the problem?
We were calling out to methods that calls `has_css?` or `has_selector?`
which returns a boolean. Since we are not using the return value, it
means the methods can be deemed unnecessary. However, we do want those
checks and this commit adds the necessarily assertions to make use of
the return values.
If we're asserting that something is missing, we want to use
`has_no_css?` instead of `!has_css?` since `has_css?` will wait the full
capybara default wait time before return if the selector is not present.
4dd053a69c addressed most of the
instability we were seeing with system tests on CI and locally. Let's
try pushing the number of parallel processes up to squeeze as much time
savings as possible from the runner.
Prior to this commit, we didn't have RTL versions of our admin and plugins CSS bundles and we always served LTR versions of those bundles even when users used an RTL locale, causing admin and plugins UI elements to never look as good as when an LTR locale was used. Example of UI issues prior to this commit were: missing margins, borders on the wrong side and buttons too close to each other etc.
This commit creates an RTL version for the admin CSS bundle as well as RTL bundles for all the installed plugins and serves those RTL bundles to users/sites who use RTL locales.
* FEATURE: reduce avatar sizes to 6 from 20
This PR introduces 3 changes:
1. SiteSetting.avatar_sizes, now does what is says on the tin.
previously it would introduce a large number of extra sizes, to allow for
various DPIs. Instead we now trust the admin with the size list.
2. When `avatar_sizes` changes, we ensure consistency and remove resized
avatars that are not longer allowed per site setting. This happens on the
12 hourly job and limited out of the box to 20k cleanups per cycle, given
this may reach out to AWS 20k times to remove things.
3.Our default avatar sizes are now "24|48|72|96|144|288" these sizes were
very specifically picked to limit amount of bluriness introduced by webkit.
Our avatars are already blurry due to 1px border, so this corrects old blur.
This change heavily reduces storage required by forums which simplifies
site moves and more.
Co-authored-by: David Taylor <david@taylorhq.com>
- ensures buttons are aligned to the bottom
- makes the emoji icon tertiary as initially intended
- correctly sets the icon scale of the sending button
- Made the emoji btn blue when composer is focused
- Moved everything chat-composer-button to its own file and BEM-ified it and making the choice to only work with our own is-disabled definition instead of with the attribute :disabled, for consistency
This should fix this failure:
```
Failures:
1) Thread list in side panel | full page when there are no threads that the user is participating in shows a message
Failure/Error: measurement = Benchmark.measure { example.run }
expected to find text "You are not participating in any threads in this channel." in "Community\nEverything\nMy Posts\nMore\nMessages\nInbox\nChannels\nRandom 25\nPersonal chat\nRandom 25\nShowing all messages\nOngoing discussions"
```
The screenshot failure was clearly showing the spinner still being present.
## What is the problem?
MessageBus by default uses long polling which keeps a connection
open for 25 seconds by default. The problem here is that Capybara does not know about these
connections being kept opened by MessageBus and hence does not know how
to stop these connections at the end of each test. As a result, the long polling MessageBus connections are kept opened by the browser and we hit chrome's limit of 6 concurrent requests per host, new request made in the browser is marked as "pending" until a request is freed up. Since we keep a MessageBus long polling connection opened for 25 seconds, our finders in Capybara end up hitting Capybara's wait time out causing the tests to fail.
## What is the fix?
Since we can't rely on Capybara to close all the existing Capybara
connections, we manually execute a script to stop all MessageBus
connections after each system test.
```
for i in {1..10}; do
echo "Running iteration $i"
PARALLEL_TEST_PROCESSORS=8 CAPYBARA_DEFAULT_MAX_WAIT_TIME=10 bin/turbo_rspec --seed=34908 --profile --verbose --format documentation spec/system
if [ $? -ne 0 ]; then
echo "Error encountered on iteration $i"
exit 1
fi
done
echo "All 10 iterations completed successfully"
```
Without the fix, the script fails consistently in the first few iterations. Running in non-headless mode with the "network" tab opened will reveal the requests that are marked as pending.
What is the problem?
There are two problems being fixed here:
1. When opening the composer, we are seeing multiple requests made to
the `/composer_messages` endpoint. This is due to our use of the
`transitionend` event on the `#reply-control` element. The event is
fired once for each transition event and the `#reply-control` element
has multiple transition events.
2. System tests have animations disabled so the `transitionend` event
does not fire at all.
What is the solution?
Instead of relying on the `transitionend` event, we can instead just
observer the `composerState` property of the `ComposerBody` component
and trigger the `composer:opened` appEvent with a delay that is similar
to the transition duration used for the `ComposerBody` component.
dependabot[bot]
Osama Sayegh
Joffrey JAFFEUX
Blake Erickson
Vinoth Kannan
chapoi
Krzysztof Kotlarek
Alan Guo Xiang Tan
David Taylor
Kris
Mark VanLandingham
Andrei Prigorshnev
Jarek Radosz
锦心
Sam
Penar Musaraj
Loïc Guitaut