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.

MSe1969 said:

Interesting, I wasn’t aware about that – so I assume, that you have observed that behavior yourself and not only read about that?

Yes I have: with a charger plugged in and the flash LED on, the phone does show the charging indicator, but the charge level is still dropping. Ampere also shows that it is in fact draining the battery:

MSe1969 said:

I guess, this would be a hardware limitation, I can’t think about a setting controlling this – however, honestly, I don’t know.

Okay, thanks anyway. Motorola probably had a good reason for this limitation, such as temperature control, and overriding it would thus be risky too, even if it were possible.

Firstly, a big thank you @MSe1969 for keeping my old Moto G (falcon) secure!

My question is about a specific feature: for some reason, Motorola has apparently disabled charging the device when the camera (flash) LED is on (I’ve found at least one Reddit thread confirming this). Do you happen to know if this is a hardware-level limitation, or if there’s any way to override it in the OS/kernel?

I’ve been testing the phone as a security camera, and while it’s otherwise working, in practical use not having the flash LED means having to have a separate light source, adding its own complications (timers and so on).

The war rhetoric feels new and weird. I thought pacifism was one of JW’s core tenets, and I’d imagine that suddenly declaring ”we are at war” to such an audience would rub them the wrong way.

Then again, maybe this has always been the rhetoric and I just missed it, just like for the longest time I missed the fact that while beards are forbidden, mustaches are not.

Ajan suunnilleen yhtä paljon asvaltilla ja hiekkasilla ulkoilureiteillä, ja tämä rengas on rullannut erinomaisesti molemmilla.

Vasta kuukauden olen tällä ajellut, joten kestävyydestä en vielä tiedä, mutta edellinen yhtä paksusti suojattu rengas kesti vuosia. Enkä lopuksikaan vaihtanut sitä puhkeamisen takia, vaan varmuuden vuoksi, kun sisempi värikerros jo irvisteli.

Hintavahan tämä on huonommin suojattuihin vaihtoehtoihin verrattuna, mutta mielenrauha on mielestäni sen arvoista, kun ei tarvi jokaisen pikku lasinsiruläjän kohdalla panikoida.

No ehdottomasti aivan tavallisen naakan päiväkirja kiinnostaa, mutta pronomineja enemmän antropomorfiselta korvaani särähtää tuo rakkaaksi nimittäminen. Ja minulle ”hän” on Ugly_Ericin sanoja lainatakseni sieluton ja tuntematon, ”se” lämpimämpi ja läheisempi.

Merenpuoleiselta pientareelta ulottuu puun oksa melkein pyörätien toiselle puolelle, pitäisi käydä sahaamassa.

Etusivu > Palvelut > Kuvantaminen > Toimipisteet: ”Toimipisteiden sijainnit näet kartalta.” Karttaa ei näy missään, eikä edes siihen viittaavaa linkkitekstiä. Käyttäjän pitää arvata, että kartta löytyy oikean laidan ”Linkit”-valikosta, ”OYS sijaintitiedot” -linkin takaa. Linkin tekstissä pitäisi mainita kartta, johon sisällössä viitataan. Vielä parempi ratkaisu olisi linkittää sisällön ”kartalta”-sana suoraan sinne karttoihin.

Etusivu > Potilaille ja läheisille > Palvelupisteet: ”Sairaalan kart​at löydät Linkit​-valikosta.” Tässä kartat-sana on linkitetty karttoihin, mikä on hyvä (ja samaa ratkaisua ehdotin edellisessä ongelmakohdassa). Sen sijaan Linkit-valikkoa ei tällä sivulla sitten ole ollenkaan, mikä tekee sen mainitsemisesta turhaa ja harhaanjohtavaa.

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.