Nice! The discussion is those two are interesting. Thanks for the links!

I've marked D17919 as fixing this although it only fixes the "hover with your mouse" half. A followup change will fix the "drag-to-select-a-range" half.

I marked D17919 as fixing this. I can't reproduce it after that change (except: the drag-select behavior isn't converted yet) and we're now Quicksand-aware, although it's possible I'm just not doing the right sequence of operations.

Maybe also T4348, but T5000 in general is on our "todo this year" list.

Interesting read. Indeed, our code is already committed and pushed (in feature branches), so Audit seems the way to go, but reviewing commits one by one is absolutely not the desired outcome.

I'd recommend reading https://secure.phabricator.com/phame/post/view/766/write_review_merge_publish_phabricator_review_workflow/.

Sorry, yes, that was a disappointing way to phrase it. You may open a thousand editors and put any number of them between zero and all of them, inclusive, into any of the various undo states.

only half of them :/

🐕

This no longer reproduces after D17916.

I'm inclined not to actually pursue the autofocus approach I was considering before, at least until we get a better read on whether click-to-select is a good behavior or not. Instead, I'm just going to fiddle with the UI a bit to fix the alignment issue. The new hidden inline state has some similar alignment issues.

(If something you care about got merged here and isn't covered at HEAD / by T12616, feel free to file a new report or feature request adhering to modern guidelines.)

I'm not sure this task has any specific, actionable issues remaining. Partly, it has just been open for twenty five decades and become a bit of a dumping ground.

I think it's also possible that this was T11784.

The keyboard reticle has been fixed but the inline reticle is still at large.

I think the keyboard reticle now generally has reasonable behavior.

max-height: 600px; overflow: scroll;

This is going to get even worse:

I've marked D17903 as fixing this. We still keep the comment focused, but comments no longer collapse en-masse after changes in T12616. Current state of the world is:

This discusses the hover/edit reticle, but the keyboard reticle has the same bug.

I believe this is now resolved by the series of changes attached to T12616. In particular, D17840 introduced Quicksand-aware state to changeset lists.

That's partly because "\n" isn't a newline in bash:

Yes, the behavior depends on the shell. I was using bash.

Ah, I see that it works differently in other shells. The above output was from zsh. In bash, indeed all output is written to the file:

It shows no output because there are no warnings. If you replace phabricator/bin/storage dump with a command that does give various formats of warnings on stderr, you see that it works:

$ sh -c 'echo "output1"; echo "error\nwarning\nerror2" 1>&2; echo "output2"' >foo.txt 2> >(grep -v warning)
error
error2
$ cat foo.txt
output1
output2

A vaguely related question... how is the /status/ endpoint meant to work behind an ELB? AWS ELB's don't pass a Host header to the healthcheck endpoint, so by default it just returns a 500. I worked around this by using some nginx voodoo to rewrite the Host header if the User-Agent header matches ^ELB-HealthChecker/\d+\.\d+$, but this is less-than-ideal.

I'm not sure this works as expected.

I used the subshell redirection trick as mentioned by @epriestley to hide this warning from our cron output as well:

In T12716#223717, @chad wrote:

I assume this is T4334

I assume this is T4334