Mar 1 2021
See also T228121.
Feb 24 2021
Correction—it actually removes the first input (i.e., the topmost one), which is strangely mildly amusing.
Feb 21 2021
Hm—on second thought, you're probably right @Barkeep49. I take back what I said earlier.
For what it's worth, my experience with OTRS so far hasn't been too bad. It does what it really needs to do, just with... a lot of downsides. (Slow, bad UX, limited functionality, etc.)
Jan 24 2021
Jan 10 2021
I'm running macOS Big Sur, here's some more screenshots with rules.
Safari Technology Preview 14.1:
Jan 9 2021
I haven't come across the original issue either (I haven't specifically tried to reproduce it, but I do use custom shortcuts). I do know that certain shortcuts like Shift+D don't work at all because they're hardcoded (see T213008), but for the most part they've worked fine for me. (Big Sur, Huggle version: 3.4.10, build: 3880 3.4.10)
I personally mark edits suspicious when I believe them to be non-constructive, but I'm unable to explain why, in policy, it should be reverted. In other words, it's a "this is probably a bad edit, but I want a second user to look at it" button for me—the ephemeral nature of it is partly why I find it especially helpful.
Jan 2 2021
Dec 22 2020
Nov 26 2020
A check somewhere (not sure where)
If it helps at all, I believe that would be here, with the blocked param being defined from User::isBlocked here.
Edit: naturally, I missed @Dreamy_Jazz's much more informative break down of the call tree here.
Nov 3 2020
Oct 27 2020
Jan 5 2019
Sorry, let me clarify. Displaying the message "No difference" like that seems to be very inconsistent with the way diffs are usually displayed. It also shows a lot of extraneous information that isn't relevant to just saying "No difference".