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

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!

Yeah, seems to be fixed: I tested in an Ubuntu 24.04 vm with WezTerm 20240203-110809-5046fc22 and couldn’t reproduce the issue.

(I first tried the nightly, which from the repository was 20260117-154428-05343b38, but that one was missing all window decorations entirely, and so couldn’t be resized at all.)

I’ll close the issue and unsubscribe, as I’m not using WezTerm currently myself. Others can reopen it if still affected.

I noticed that for the specific case of picking an element from the end using just the size of the array itself, the above is a somewhat contrived example; a plain -1 would work just as well. But I can change the example script as below, and the difference between outputs still holds:

#!/bin/bash

array=(
    "a"
    "b"
    "c"
)

i=3

value="${array[i - 1]}"

printf "%s\n" "${value}"

With the same arguments given, output differs between 3.12.0 and 3.13.0, as demonstrated in the example below. I didn’t see this mentioned directly in the release notes, so I was wondering if this is an intentional change or a bug. I don’t mind the change per se, but just wanted to be sure that it’s permanent before I adjust all my existing scripts to conform to the newer way shfmt prefers this.

$ cat asdf
#!/bin/bash

array=(
    "a"
    "b"
    "c"
)

value="${array[${#array[@]} - 1]}"

printf "%s\n" "${value}"

$ /usr/local/bin/archive/shfmt/shfmt_v3.12.0_linux_amd64 -i 4 -ci -l -d asdf # no output

$ /usr/local/bin/archive/shfmt/shfmt_v3.13.0_linux_amd64 -i 4 -ci -l -d asdf
asdf
diff asdf.orig asdf
--- asdf.orig
+++ asdf
@@ -6,6 +6,6 @@
     "c"
 )
 
-value="${array[${#array[@]} - 1]}"
+value="${array[${#array[@]}-1]}"
 
 printf "%s\n" "${value}"

Still an issue in Matheria 7.2.2.4 (server version 32.0.5).

This also manifests a bit differently when using the lock screen player: resuming playback after the call actually skips back to to the start of a previously played track instead of resuming the current one (from where you were when the call came in). The player even shows the current track title, despite playing a different one.

Steps to reproduce this variant:

1. have a directory with two audio files, 1.m4a and 2.m4a
2. start to play 2.m4u
3. lock the screen
4. call the phone (just have it ring, then hang up)
5. resume playback from the lock screen

Expected behaviour

Playback of 2.m4a resumes from where it was when the call came in

Actual behaviour

The player beings to play 1.m4a from the start (but claims to play 2.m4a)

4.7.1 was released three weeks ago, but as I’m writing this, prebuilt binaries have yet to appear on the release page. Maybe the build jobs have failed?

I’m still getting federated posts from updating old ones on my blog (with the plugin now at version 7.5.0). Not every time, but something like four out of maybe two dozen that I edited today (from 2018) have so far appeared on Mastodon.

Should I open a new report? I noticed the merged PR (above) mentions the block editor, whereas I’m using the classic editor.