Thank you @ppelberg for finding and collecting these feedback!

WIP sticky reply widget:
http://patchdemo.wmflabs.org/wikis/7a9167060277b7c311ff7045ca1a1e9e/w/index.php/Talk:Main_Page?dtvisual=1

Task description update

• Adding a link to the feedback @dialmove shared RE issue 1a. to the task description:

Second impression is "Where am I"? When clicking a post that has several earlier replies, the interface jumps down and the tool appears in the middle of a completely different conversation, in a new context with no visual indication of its relation to the initial comment we're replying to. | Source

• Adding the issue @dialmove raised RE the "Reply" button disappearing from sight when composing a long comment in source

When writing a long comment in the Reply tool's source mode, the "Reply" button can disappear from sight [because of the Preview].

Re: 2a, we need to address the intermediate state for the "Reply" links elsewhere on the page that become "grayed out"/disabled when someone has the Reply tool open. see: T234403

Task description update
Adding the feedback @Gnom1 shared here to the task description as Issue #5:

I expected the edit window to open right under the comment that I selected to reply to, but it opened further down the page. So I asked myself whether my comment would end up further down instead.

Copying over some relevant comments from another ticket...

In T255085#6216287, @dialmove wrote:

Reddit in paticular has an intuitive comment editor, which resembles a lot what you're building here. They have an advantage though, their comments are shown in reverse order (recent commments first) so they don't have the problem that newer comments in long threads will be thrown all the way down to the end.

Maybe you could temporarily show the new post right below the comment you're replying to, just in the client side, yet still store it at the proper place of the thread, so that it will be moved when the page is refreshed.

Task description update
Adding a link to the feedback @Kaartic shared here to the task description as part of Issue #1b.

It would be nice to visually distinguish the editor so that it is easily identifiable amongst the content while scrolling through the page. When drafting a reply, I happened to scroll the page to see other content but lost track of the location of the editor. It took me some time to find this. Given that the positioning of the editor could vary unlike the editors in other places, I guess it would be nice to visually distinguish this in a better way so that it could easily be identified.

In T254208#6184943, @Esanders wrote:

WIP sticky reply widget:
http://patchdemo.wmflabs.org/wikis/7a9167060277b7c311ff7045ca1a1e9e/w/index.php/Talk:Main_Page?dtvisual=1

For reference: Patch 601350
Related: T252445#6180738 - Keep (sticky) the toolbars on screen

@Esanders what's the benefit of using position: fixed + JS compared to position: sticky + no JS?

Browser support?

Sorry, I've only linked it on the patch: https://caniuse.com/#feat=css-sticky
IE is out of the game. I wonder if that was the thinking behind the decision.
I think there are very few editors who use IE and talk pages, if any.

Well this is not a thing to debate, there must be some bulletproof statistics. Anyway from my experience, on Czech Wikipedia there is a surprisingly big number of IE users even today.

Task description update

• ADDED the newly created ticket (T257176) for issues "2A" and "2B" in the task description's "Feedback" table.

In T254208#6184943, @Esanders wrote:

WIP sticky reply widget:
http://patchdemo.wmflabs.org/wikis/7a9167060277b7c311ff7045ca1a1e9e/w/index.php/Talk:Main_Page?dtvisual=1

When I click “cancel”, it jumps back to the comment I started replying to, because it focuses on the now-visible reply button. It was surprising for me, I would expect to stay where I am.

In T254208#6255862, @Dvorapa wrote:

Well this is not a thing to debate, there must be some bulletproof statistics. Anyway from my experience, on Czech Wikipedia there is a surprisingly big number of IE users even today.

As long as IE11 is Grade A, not even any statistics can justify not supporting it. If we say we support it, we should support it as much as possible. Convenience is not a reason not to support it. However, something like this could work:

&-fix-top,
&-fix-bottom {
	position: fixed;
	position: sticky;
}

This makes it transition from one state to the other more seamless on modern browsers, while keeping support for IE. (Exactly this didn’t seem to work for me, but probably it can be made work.)

Task description update

• Issue 3 will be considered as part of T252445; the "Feedback" table has been updated to reflect this.

Task description update
I've created a task to address – what I understand to be – a root of Issue #5:

5.

Expected the Reply tool's compose window to open right beneath the comment being replied to. TBD: whether the tool's behavior became clear to this person after they posted their comment.

T259834

@Gnom1: https://w.wiki/USH.

Sticky is bounded by the parent element, so I don't think position sticky can be used here due to the widget being embedded deep in the DOM to take the correct position within the list.

One could hoist the widget out of the tree structure and then fake a placeholder and dynamically resize it, but that would result in more JS size computation and positioning, which would be slower overall.

Change 601350 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/DiscussionTools@master] WIP sticky replies

https://gerrit.wikimedia.org/r/601350

Test wiki created on Patch Demo by ESanders (WMF) using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/f7c62edd11ec30610e13c39c144ff94e/w/

I played a bit with the patchdemo (it’s very useful, many thanks for inventing and using it!). Some issues I found:

• The reply interface is actually huge. Without any content, the source mode occupies about 40% of my ~700px viewport height when logged out (i.e. with anon warning), the visual mode even a bit more. If I scroll on the page, I probably want to something else than the reply interface. Maybe an option to collapse the interface into one line in floating mode?
• If I write enough, the interface becomes higher than my viewport. If I start scrolling in this state, there’s no way to get back into non-floating mode, and no way at all to see the top of the draft.
• The SyntaxHighlight boxes (e.g. § Upon creating an article) and The Earwig’s opaque (style="opacity:0.8;") signature (e.g. § Uploads disabled vs. Permission error) get above the interface in both Firefox and Chromium if, and only if, the reply’s natural (non-floating) position is above the code block/signature. The signature issue definitely looks like a browser bug, yet it occurs in both browsers…
• Sometimes (e.g. if I use anchor links, like the ones in the table of contents), the interface may end up on the wrong side of the screen (i.e. at the bottom instead of at the top or vice versa).

Test wiki on Patch demo by ESanders (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/f7c62edd11ec30610e13c39c144ff94e/w/

Test wiki created on Patch demo by ESanders (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/cc54aa1d20/w/

@Esanders and I were discussing that the design should consider:

• height of reply "popup"
• if there is a preview
• if there is also a notification to sign in
• if there is a notification that many people are replying simultaneously.

Change 601350 abandoned by Esanders:

[mediawiki/extensions/DiscussionTools@master] WIP sticky replies

Reason:

When with the floating "Return to.." button instead.

https://gerrit.wikimedia.org/r/601350