Also, I tested the 94.0a1 nightly now, and the issue is still present.

I ran mozregression like this (twice, to be sure):

MOZ_ENABLE_WAYLAND=1 mozregression --profile /home/jani/.mozilla/firefox/fyaus28k.LP1940417 --bad 91 --good 89 --profile-persistence clone-first

Here’s the result (it was the same for both bisects):

5:25.73 INFO: No more integration revisions, bisection finished.
5:25.73 INFO: Last good revision: 9f0fbb1431721c9eae68a3c94ae49a4d33fdb1f8
5:25.73 INFO: First bad revision: 7b82d177a6b979036f180329be6b029d690d9e0c
5:25.73 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9f0fbb1431721c9eae68a3c94ae49a4d33fdb1f8&tochange=7b82d177a6b979036f180329be6b029d690d9e0c

According to that log, this changeset was introduced to address #1661516.

Describe the bug
The email with updates from the last 24 hours lists identifications, and mentions the name of the user having made the ID. The name is apparently supposed to be listed three times (!), but the middle occurrence is ”untranslated”, resulting in it being rendered as ”User S” for all identifications listed in the email.

Tooltip text for the ”User S” string says ”translation missing: fi.user_s_id”, as I’m using the fi locale, but user_s_id is nowhere to be found in Crowdin, nor in current en.yml, so I suspect this is independent of the locale. The reference to user_s_id is in _update_email_activity.html.

I don’t know if this is doable, but after fixing this broken reference, I’d remove the first (header) mention of the identifier from the email altogether, since it’s followed by a listing of all the new identifiers anyway, so mentioning just the last identifier’s name in the header is redundant and confusing.

Also, rather than fixing/adding the currently broken ”User S” reference in the source, I’d remove it too, since the identifier’s name is already listed (for the third time!) right after the ID.

To Reproduce

1. Subscibe to email updates.
2. Have your observations identified in the last 24 hours.
3. View the email update listing the identifications.

Observed behavior

Expected behavior
(A mockup of how the simplified view I’d prefer to receive. Sorry I didn’t have the email in English to base this on.)

Context
I’m using Gmail with Brave if that’s relevant.

There’s no gnome-shell-extension-dashtodock package for focal [1], but I did try with Dash to Dock from extensions.gnome.org, and could not reproduce the issue with it. I tried with the default settings, as well as after recreating the look & feel of Ubuntu Dock as much as possible.

Dash to Dock has customizable action for the scroll (to either switch workspaces or windows, or to do nothing), and all of those also worked just as expected.

I also noticed that using the two finger scroll function of the touchpad on my laptop does *not* trigger this (whereas using the mouse on it does).

* [1] https://packages.ubuntu.com/search?keywords=gnome-shell-extension-dashtodock

Previously: #828

Do you want another log for that? Because (as I already mentioned above), this also reproduces when using a newly-created user, so that means no unsupported extensions.

I can reproduce the crash at will with the steps I listed above, so I don’t have to wait for it to happen. It also doesn’t forcibly log me out, so I can enter those commands by just having a terminal window present when I trigger the issue. But I logged out here (after triggering) anyway since you instructed me to log in, in case it matters.

Also, there’s lots of noise in these from Boinc, thanks to #1876313.

@FlexW I’ve now rebased and pushed the changes, hope this works for you. I don’t see a way for me to merge this myself here, ”Only those with write access to this repository can merge pull requests.”

1. There’s nothing in /var/crash
2. There are no reports on the page for this computer.
3. Done, still nothing in /var/crash.

I don’t know if this means it’s not a true crash, although visually all the indications are there.

I also verified that this reproduces when using a newly-created user (with the only change from defaults for it being switching to Wayland), and also on another computer (also running 20.04). I am limited to using the one mouse that I have, so that all testing so far has been with the same mouse.