inj3ct0r
(inj3ct0r)
September 26, 2023, 9:26pm
1
Hello, I hope you are well.
after last update today i got a crashed user card
and it down with main container
2 Likes
simon
September 26, 2023, 10:04pm
2
There used to be special handling of the user card position for RTL locales: discourse/app/assets/javascripts/discourse/views/user-card.js.es6 at 4896a7dec79203cd44265bb2372c2b4a223c3d26 ¡ discourse/discourse ¡ GitHub
With the updates to the user card, that seems to have been removed. The left
position in the user cardâs inline styles is wrong for RTL locales. From memory, I think the easiest way to deal with it is to set a right
position for the user card when an RTL locale is used. The left
and right
properties canât just be switched in the inline style rule though.
1 Like
inj3ct0r
(inj3ct0r)
September 26, 2023, 10:36pm
3
Hello, New Update
the Reply button doesnât work
2 Likes
simon
September 26, 2023, 10:46pm
4
It âworksâ, but the post editor isnât usable.
These issues can be reproduced on Meta if you select an RTL locale for your interface language:
Edit: the issue Iâm finding with the composer on Meta seems to be related to GitHub - discourse/discourse-full-width-component: Make Discourse occupy the full browser width .
The issue with user cards can be reproduced on either Meta or try.discourse.org in safe mode .
Also, the user-tip modals are incorrectly positioned for RTL locales in safe mode :
2 Likes
inj3ct0r
(inj3ct0r)
September 26, 2023, 10:51pm
5
it doesnât work in my forum for me and for my members
1 Like
simon
September 26, 2023, 11:31pm
6
Can you try loading your site in safe mode to see if that fixes some of the problems? To do that, append the following onto the URL in your browserâs address bar:
?safe_mode=no_themes,no_plugins
For example https://try.discourse.org/t/what-do-the-avatars-in-the-topic-list-mean/65?safe_mode=no_themes,no_plugins
3 Likes
inj3ct0r
(inj3ct0r)
September 26, 2023, 11:56pm
7
yes it fix the reply button but the user card still broken
1 Like
Osama
December 15, 2023, 3:45pm
12
Hi @inj3ct0r
This has been fixed via this commit:
committed 10:16AM - 15 Dec 23 UTC
Float-kit elements (menus/tooltips) are positioned where they should be by setti⌠ng an inline `left` property in JavaScript when they're rendered. For some reasons, we also set `left: 0` on float-kit elements here:
https://github.com/discourse/discourse/blob/25d9927785b07697132504fca77b8156600966ff/app/assets/stylesheets/common/float-kit/d-menu.scss#L11-L15
This property is overridden by the inline property that the library sets in JavaScript. However, in RTL mode, all of our scss files are flipped where everything left becomes right and vice versa. In this case, the `left: 0` property in the scss file above becomes `right: 0`.
This results in a conflict specific to RTL mode where both the `left` and `right` properties are defined on the same absolute-positioned element; the `right` property will always be set to 0 because it comes from the (flipped) scss file above, and the inline `left` property will be set to some px amount determined in JavaScript.
The `right` property will take precedence over the inline `left` property due to the page being right-to-left (source: https://developer.mozilla.org/en-US/docs/Web/CSS/right#description) and this causes float-kit elements to incorrectly always stick to the right.
This commit removes the `left: 0` property altogether for float-kit elements from our scss files. It's not clear from git history why the property was added, and removing it doesn't seem to cause any issues.
Meta topic: https://meta.discourse.org/t/positioning-issues-with-rtl-locales-after-recent-updates/280220?u=osama
2 Likes
Osama
Closed
December 19, 2023, 3:45pm
13
This topic was automatically closed after 4 days. New replies are no longer allowed.