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.

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.

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:

I think we're mostly in the clear, now. This stuff likely introduces some bugs beyond the (mostly minor) ones I'm aware of, but I think it's all correct enough in the substantial ways. I'm going to take a break for a bit; I may get back to it tonight and land everything or may wait until tomorrow.

All of the inline comment icons got mis-aligned slightly a while ago. This is particularly visible with "Reply", I think. Note that the tooltip is centered, but the icon is too low (I think?) and too far to the right.

@jeffprouty Shoot us an email at support@phacility.com with details about your instance and the issue you're hitting if you're a paying customer; see also https://admin.phacility.com/book/phacility/article/support/.

Go for it, a couple emails came in that I'm still digging through. Thanks!

We currently (at least, in theory) prevent this situation from ever occurring by preventing simultaneous tagging with both "Warp Drive > Thermocoupling" and "Warp Drive > Milestone 1". Since a task can not appear in both a milestone and subproject of a particular parent task, users can never be faced with the opportunity to perform a destructive drag operation.

Many of the patches you've personally contributed in the past have bypassed the bulk of the requirements under the "Rise to Prominence" clause of Contributing Code, since you have a history with the project, are a member of Community, and have generally contributed very focused patches with clear context:

Okay. When a task is in "Warp Drive > Thermocoupling" and "Warp Drive > Milestone 1", and you view the "Warp Drive" board and drag the task from "Milestone 1" to "Backlog", what do you expect to happen to the projecs the task is tagged with?

Per above, see Planning. If that isn't clear, let me know how we could improve it.

Do you expect a task to be able to be tagged with "Warp Drive" and also simultaneously tagged with subproject "Warp Drive > Thermocoupling"?
Do you expect a task to be able to be tagged with "Warp Drive" and also simultaneously tagged with milestone "Warp Drive > Milestone 1"?

This should now be resolved in HEAD of master and stable. Thanks for the report!

I'll just ship up the "unbreak" diff, and you can either counter-diff me or figure out something else.

I think more narrow reproduction instructions are:

I can't reproduce this. Here's an example of a profile working correctly for me locally:

Select "Order By: Creation (Newest First)" or "Order By: Creation (Oldest First)".

ah mkay