I think if we combine dropdown with keyboard hints, it'd be a good middle ground.

I'm not sure if D17908 is going to stick, but if it does we more reasonably have room to add a caret menu here. I'm not planning to necessarily pursue this in the current iteration, but I believe there are no longer any meaningful technical blockers, just some product questions which will more or less resolve themselves if everything sticks.

I just want to note that we fixed this in less than 5 years. Learn how in my upcoming book "Unbelievably Agile Ultra-High-Velocity Software Development Which Goes So Fast it Almost Must Account For Relativistic Effects".

If a linter could theoretically catch it (conventions, space, formatting, etc.), I think a linter should (in a perfect world) be catching it.

Do you bucket style guide violations with lint issues? While I obviously can't post internal reviews, I can give you a hand-waving indication that a non-zero percentage of comments are style-related things that aren't caught by linters.

Broadly, the technical stuff here is in fairly good shape now but I still don't truly understand what problem we're solving. From earlier, I dug this up:

I'm just going to merge this into T8250. I'm still unsure what's to become of this, but I think however that resolves will cover this.

This is effectively not a problem at HEAD, although I may make it a problem again soon. But I'm also not sure if anyone else has actually hit this, and it's a pain to fix, and even in the worst case it's less bad now because we pointer-events this. I'm just going to punt for now, let the dust settle on T12616, and we can revisit this if anyone's actually hitting it after all that.

Per T10563#221154, D17938 makes "reply" put comments in the right (threading-respecting) place and marks this complete.

I can no longer reproduce the edit issue at HEAD.

In this screenshot:

On mobile, the hamburger menu icon is not aligned properly:

This no longer reproduces for me at HEAD of master.

We currently have three distinct selection states which I think are a little muddy. The first is the keyboard selection cursor, which shows what is selected with the keyboard:

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.

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.

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.