Specifically, this was already improved by D15726 in April 2016.

The revision editor and diff editor should no longer be racing to edit the diff. The two revision editors may be racing now, but that race is significantly easier to resolve if it crops up.

This should work again now. The behavior probably needs refinement -- I don't remember exactly where we left it and I think there was some disagreement about who should or shouldn't receive build failure notifications before D10911 accidentally disabled this, but I think T9892 and other Harbormaster tasks discuss most of that.

Chrome upstream has patched this, now:

From elsewhere:

I'm not actually sure which will end up being easier, I think they have like 95% of the same problems. Quick Create probably is a bit easier, though.

Haha, maybe it's like when Blizzard uses a simulator to build a colorblind mode they screw it up, therefor the simulator must not work?

Ah, cool. I'm 100% onboard with it if an actual affected user has confirmed that the change is good, I'm just really uneasy about accessibility changes that don't actually involve the affected users.

Do you specifically not want to add a red-green colorblind mode to the existing "Accessibility" settings?

If a change only had one of those colors (e.g., just one added section, or just one removed section) I think I'd have no clue if it was removed-red or added-red.

You were thinking about doing this one first, then Home later, right?

That's easy to add, but I'd worry it will result in much worse readability for all users for diffs with a lot of small corrections. If there are just 1-2 big edits the extra "+" and "-" probably aren't a big deal, but choppier edits will get a lot of extra annotation.

100% accurate mockup of this feature

I'm hesitant about using math to solve this because I think Blizzard did that in Overwatch (apparently? or something?) and ended up with modes that were worse for colorblind users than users with normal vision:

What version of Phabricator are you running? See Providing Version Information for help.

Cool, glad things are back in working order. Thanks for following up.

I believe this reproduces by following the steps in T11537#192019, but deleting all timestamp information completely.

This is working as intended.

What color scheme would the user prefer?

I was able to reproduce this at HEAD and D17134 should fix it, but please make sure future issues you report are against upstream code -- not forked local code -- and that your install is up to date. Many issues are already fixed by the time they are reported, and we are powerless to troubleshoot issues with local code even if we wanted to.

See Consulting if you'd like a one-on-one answer from the upstream.

Please see Contributing Feature Requests for instructions on filing a feature request which can become a maintainable feature in the upstream.

Specifically, the limit is enforced here. You could remove this limit locally if you are not concerned about the usability of the result:

This is not a bug. The element has a minimum height because viewing or selecting text from a tiny element would create usability issues: imagine trying to select 30 lines from the middle of a 100-line block with lines=2.

See Planning for more information on understanding timelines and priorities, which also answers your question. Thanks!

I think the desired behavior is to silently drop the notifications, yes. Specifically, they should be dropped in PhabricatorMailReplyHandler->filterRecipientUsers().

No clue how to reproduce this.

This recently got rewritten in connection with T11114 and I didn't come up with a way to reproduce it. Not sure if it's still an issue, but we need better reproduction steps if it is.

This is older than time itself and does not meet the modern standards for a feature request. In particular, I have no idea what problem it was intended to resolve and nothing that has been linked here in the last couple of years gives me much of an idea. There are likely better approaches in a modern context (T5873, T3875 + T11355, maybe?). If you want this for some purpose, feel free to file a new request describing your problem in better detail. T11355 is probably the most relevant?

I can't reproduce this at HEAD. I suspect D14853 resolved it.

T11114 has fixed the web-originated-edit versions of this, where your "Edit Revision" or "Change Reviewers" action spans another edit.

Isn't the right answer to make the web interface reject things that would choke the parser?

The underlying issue here is that fields may, in the general case, contain multiple paragraphs, colons, things that look like field headers, and may be line-wrapped. We must parse this as two fields:

I'm going to dump everything into master now because I believe any disastrous brokenness should be reasonably easy to fix at this point.