After updating my build of the mobile app from 2.40.0 to 2.41.1 (and no other changes in the build environment), all icons in the resulting app have been replaced with a ”☒”, and all channel icons with what looks like a Chinese character (the app is supposed to use English, like the OS). Only user profile pictures seem unaffected (except for the overlaid status indicator, which *is* affected).

I’ve so far tested this on a phone running Android 10 and a tablet running Android 15. Both are using the ”Onyx” theme (and switching the theme has no impact on the issue). The server is running the latest release 11.8.1 (and the web UI is unaffected).

Sorry, I was tracing this on a test site using a mockup, and apparently the <span> is actually only added once the post is published, so the issue doesn’t manifest when using previews. That’s why I never caught it while actually writing the posts and using previews, only after publishing.

The trailing <span class="__iawmlf-post-loop-links"> element introduced in PR #338 causes WordPress to render a trailing newline as a <br /> tag in the last paragraph. This behavior differs from when Link Fixer is not active.

I don’t know if the block editor is affected, since I don’t use it, but the issue is present when using the Classic Editor, and even there you have to use the Code view (because Visual view either converts the trailing newline into a line with an  , or strips the trailing newline when switching to Code view).

My guess is that this is wpautop trying to be smart about the content, seeing the trailing <span> from Link Fixer, and thinking it’s visible content, so the trailing newline in the actual content (as entered in the editor) should be rendered as a visible <br /> too.

This is probably a very niche issue, and I’m sure I can figure out a way to work around it, but I wanted to document it anyway.

Steps to reproduce

0. deactivate Link Fixer
1. use Classic Editor’s Code view to create a post
2. end the final paragraph with a newline
3. preview publish the post and inspect the last paragraph: there is no newline before the closing </p> tag
4. activate Link Fixer
5. create another post with the same contents
6. preview publish the post and inspect the last paragraph

What you expected to happen

the <span> to immediately follow the last word and immediately precede the closing </p> tag, with no newline before or after

What actually happened

the <span> is separated from the last word with a <br /> tag followed by a plain newline

I fired up 152.0a1 (from nightly), did my steps above, and could no longer reproduce the issue. So it does seem to be fixed!

I know I’m not the one the request was directed to, but I’ve attached my log anyway. What I did to produce it:

1. MOZ_LOG="WidgetScreen:5,WidgetWayland:5,Widget:5,WidgetPopup:5" /usr/bin/firefox >log.txt 2>&1
2. opened the Wikipedia article for Firefox
3. powered off both my monitors, then powered them back on
4. tried right-clicking many of the links on the page
5. quit Firefox

Reproducible for me in Ubuntu 24.04, Firefox 150.0 from Mozilla’s PPA, with a small difference: new tab button does seem to work, which is useful, since without it wouldn’t be possible to open about:config the workaround of toggling widget.wayland.fractional-scale.enabled.

A small addition: Firefox 150.0 (from Mozilla’s PPA) is similarly affected for me, so this is indeed an upstream one.

This looks like #2851 on the COSMIC issue tracker, affecting Firefox. They’ve also reported it upstream.

The COSMIC issue has been closed as having been fixed by 150.0, but there’s at least one dissenter.

Anyway, I’m using a regular Gnome desktop on Ubuntu 24.04, with Wayland, Librewolf 150.0, and funnily enough, for me this only appeared with 150.0 and not before. So now I am affected.

The workaround of toggling widget.wayland.fractional-scale.enabled mentioned in the COSMIC issue seems to work (i.e. after the menus have died, open about:config, toggle the setting from default trueto false, then immediately back to true).

Using a supported version?

• I have searched open and closed issues for duplicates.
• I am using Signal-Desktop as provided by the Signal team, not a 3rd-party package.

Overall summary

I’ve set notes to self to disappear after 1 day. I chose one message to be pinned, was prompted to select the time to pin the message for, and selected 7 days. I was shown the message in the title.

I’m now unsure whether the message will be unpinned and removed after 1 day or 7 days. My guess would be 7 days, but either way, I think the message should make this explicit, or at least unambiguous wrt. which timer takes precedence.

Steps to reproduce

1. set notes to self to disappear after 1 day
2. send a note to yourself
3. choose to pin the message
4. select to pin the message for 7 days

Expected result

Any of these, in order of preference:

1. ”This disappearing message will be unpinned and removed from the chat after 7 days.”
2. ”This disappearing message will be unpinned and removed from the chat after 1 day.”
3. ”Disappearing messages will be unpinned and the removed from the chat when the pinning timer expires.”
4. ”Disappearing messages will be unpinned and the removed from the chat when the disappearance timer expires.”

Actual result

”Disappearing messages will be unpinned when their timer expires and the message is removed from the chat.”

Screenshots

No response

Signal version

8.7.0

Operating system

Ubuntu 24.04

Version of Signal on your phone

8.6

No worries, thanks for the fix!