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.

Asiakaspalvelijat sinänsä ihan ystävällisiä, mutta asiointi vikailmoitusasioissa heidän kanssaan on silti turhauttavaa, koska heillä ei (varsinkaan virka-ajan ulkopuolella) tunnu olevan muita työkaluja kuin samat alkeelliset mitkä chattibotillakin: modeemin uudelleenkäynnistyttäminen, kaapeleiden varmisteluttaminen ja modeemin nollaus. Edistyneenä käyttäjänä osaan kyllä yleensä erottaa tilapäiset ja varsinkin omista toimistani johtuvat häiriöt sellaisista, joiden syy on jossain antennipistokkeeni ulkopuolella.

Myös kaksitasoinen häiriökirjanpito turhauttaa: asiakaspalvelulla on ilmeisesti enemmän näkymää häiriötilanteisiin kuin mitä DNA:n julkisella sivustolla annetaan. Tämän takia vikailmoituksen soittaja tulee aina jo lähtökohtaisesti vähän kuin hattu kourassa asiakaspalvelun puheille, että saisikos vähän tilannetietoa. En tähän mennessä (~ 10 vuoden asiakkuuden aikana) ikinä ole julkisen sivun tiedotteista saanut akuuttia tietoa paikallisista häiriöistä silloinkaan, kun ne ovat olleet laajempia. Tämänkertainenkin vika alkoi ja päättyi täysin minusta riippumattomista syistä, enkä edelleenkään tiedä siitä sen enempää, koska vikatiedotteet eivät kerro mitään. Postinumerotason tietokin riittäisi, vaikka vika olisi vain yhdessä taloyhtiössä sen alueella.

Kuvittelisin, että keskuslaitteista on jatkuva näkymä asiakaslaitteiden tilanteeseen, joka toimisi herkkänä indikaattorina laajemmista häiriöistä. Julkinen häiriötiedotus voisi tarjota pelkistetyn, reaaliaikaisen näkymän samaan tietoon: kuinka monta epänormaalia signaalia keskuslaite tällä hetkellä saa asiakkailta, millainen on sen viime päivien kehitys, ja millä kynnyksellä se aiheuttaa huoltotoimenpiteitä.

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!

I can’t remember when exactly this began, but for maybe a few weeks now the first clicks of the share button in the web UI just give a ”Sharing is not available for private podcasts” notification at the bottom corner. This is for any and all podcasts, so not just actually private ones. After two or three clicks the sharing dialog then finally does pop up.

My main browser is Librewolf (based on Firefox), but the same issue occurs in Vivaldi too (which is based on Chromium).

There’s nothing in the browser’s console about this (no errors at all).

I made a screencast demonstrating the issue: https://youtu.be/5_LieFpsz0I

Both issues (”Network is unreachable” and WoL not working) were fixed for me after the latest kernel update, which was Linux 6.8.0-106.

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}"