I'm not exactly sure what this is asking for -- it sounds like you just want a more convenient way to post a comment asking revision authors to "Please re-run the optional tests."?

I think you're free to fiddle -- there are some more adjustments and things, but nothing too significant. I think the only other really CSS-ish thing is that if you search for events in a specific range (July 5-7) on a calendar view, I'd like to make it clear which days your query covers.

This is working as intended.

After D16333 there's still a tiny amount of unique spelling correction code in Arcanist, but it's just calling into libphutil and part of code duplication which would be better resolved elsewhere (like T7487).

For completeness, I'll also drop a mention of T5024 here, although I'm not yet sure how the two might tie together.

We do not currently support RTL languages. You can follow T5267 for progress on internationalizing Phabricator, but we currently expect to support LTR latin languages first and it may be some time before we support RTL languages.

You are in the wrong place -- it looks like you mean to be on Uber's internal install of Phabricator, but this is the public upstream install of Phabricator.

Oh, I forgot to mention this but T10333 (groups within columns) is another possible attack here, and one I definitely intend to implement regardless of other work and outcomes (e.g., T5474) since I think it stands on its own and is already well-justified by confusion with priority-ordered boards. T10333#158767 has the ASCII-art mock:

Thanks for the report, and for providing detailed reproduction steps.

Phlux should probably be on the chopping block too since Almanac pretty much obsoleted it in Phacility production.

Here's an effort to collect use cases for the hooks I plan to break or replace:

Concretely, I think this breaks down as a mixture of modernizations and new code:

Changes connected to T8116 implement the initial server-side version of this. It's still very skeletal, but we probably need to make some client changes to move forward. In particular, the next object to implement is probably Signature, but signature algorithms should live in the client since the client will need to be able to verify signatures.

I'm just going to consolidate this into T5055, I think they're pretty much the same task at this point.

Given my description, what other behavior do you think it might have?

(T11357 is a companion issue for Files.)

D16323 uses <input type="text" pattern="\d*" />, which appears to have the best behavior.

On iOS 9.2 in the simulator, <input type="number" /> gives you this keyboard:

Oh, there's a "Toggle Software Keyboard" option that I somehow disabled.

On iPhone Simulator, the behavior of <input type="number" /> appears to be "draw the keyboard for 1 frame and then immediately hide it".

Offhand, do you know if <input type="number" /> has the desired behavior on your device?

What behavior do you expect?

What would you like us to do differently?

This is working as intended.

Specifically, I'd like to understand what concrete pathway led you to encounter this. A list of hypothetical situations isn't useful in anticipating or recovering from broader problems.

Why are you running arc install-certificate with a manually entered URL?

Part of the tension here is that any package-related command potentially has two targets: arc itself, or the current working directory (Phabricator, some third-party app you're developing, etc).

None of that really does anything yet, but the next steps (signing, installing) need to have major components in arc, so I'm going to consolidate this into T8115 / T5055 and other related arc work.

(We could detect this case and fail with an error, but the root issue here seems to be that tracking is being set on a remote branch which the local branch really does not track.)

Generally, I'm very hesitant to use "will the push change anything" as a signal, because I think this is unintuitive and will create confusing false negatives. Specifically, if you do this:

Have you asked Sourcetree or Git Tower to change their behavior instead? They can compute ahead/behind without setting tracking, and it seems like setting tracking is not really correct here (the local branches do not really "track" temporary remote CI branches in the traditional sense).