@MichaelSchoenitzer_WMDE can you double check this please? I get larger text areas, if the text inside is larger, e.g.

@Lea_WMDE: Not sure what you mean. I'm talking about the edit-mode. There the textarea is always 6 lines high:

Change 469860 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/TwoColConflict@master] Perfect initial text editor size in JS editing mode

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

Change 469860 merged by jenkins-bot:
[mediawiki/extensions/TwoColConflict@master] Perfect initial text editor size in JS editing mode

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

This does not work yet for me.

Maybe it has something to do with the other side being rather short?

Change 471009 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/TwoColConflict@master] Two-phase <textare> height calculation when activating edit mode

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

Uh, that's an edge-case we should look back at.

How it currently works is that it looks at the other, non-editable side and makes sure the editable side is at least as high as the non-editable side. This works perfect in all cases where both sides show almost the same text. In your example, the non-editable side is very small. I can't think of a "perfect" way to fix this, but I have an idea to at least radically improve this situation. Patch follows.

Change 471009 merged by jenkins-bot:
[mediawiki/extensions/TwoColConflict@master] Two-phase <textare> height calculation when activating edit mode

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

So now I get a different problem, it seems like the height of the editor is always the height of the text of both sides combined:
The end of the text chunk looks like this when not in editor mode:

The first two screenshots are cut down so much that I can't understand the situation any more.

The idea is that the orange box stays the same size when you click edit. I will assume this was the case in your test. Now it might be that the font you get in edit mode is much smaller than the variable size font in non-edit mode. This would explain why the <textarea> you get has so much empty space at the bottom. It looks like this is what happens for you. There is not much I can do about this, unfortunately.

One suggestion, though: It might be worth limiting the height of the <textarea> to the height of the browser window. Otherwise you might end with an editor thats hard to use because the scrollbar (there is none when you start editing, but you get one the moment you add a newline to the text) spans multiple screens, and you can't even see it properly. This tiny update might make the problem you are running into much easier to deal with.

In T207163#4715247, @thiemowmde wrote:

The idea is that the orange box stays the same size when you click edit.

Oj,I totally get your point, but I was thinking sth different the whole time without realizing it until now:
I did not expect the box to stay the same size, but the text in the box to be readable. My hypothesis is that to the user it does not really matter if the box size is still the same, but rather, if the box contains all the text that is being displayed right now. Would it be possible to make the size of the text box dependent on the text it is actually displaying (initially of course). So you don't use the display font for calculations, but the dimensions the text has during editing?

One suggestion, though: It might be worth limiting the height of the <textarea> to the height of the browser window.

That sounds great! Let's do this :)

My hypothesis is that to the user it does not really matter if the box size is still the same, but rather, if the box contains all the text that is being displayed right now.

I'm totally with you here. The problem is that I don't know what size the <textarea> would need to perfectly fit the text inside. I can think of one way to achieve this: Make the non-editable text visible for a brief moment, measure it's size, hide it again, and make the <textarea> visible. But this would come with visible flicker, not so nice code, hard to test, and possibly slow performance (probably acceptable, as this code would only kick in when one of the edit pens is clicked).

limiting the height of the <textarea> to the height of the browser window.

That sounds great! Let's do this

I was thinking about this and found it would create a problem when both sides are very large (much larger than one screen). The height of the <textarea> would be limited, but not the other side. After the first screen the two sides would not line up any more, as the <textarea> would start to scroll independently from the other side.

Solutions I can think of right now:

• Limit the height of both sides, and add code that synchronizes the scroll positions of the two.
• Keep the status quo, where both sides are so large that they (initially) do not have scrollbars.
• Use the available window size only as a limit when editing the larger side. I attached an example. Think of the top and bottom borders of the screenshot as the edges of the window. In this situation, there is no benefit in making the <textarea> larger than the screen. The contrary: When the <textarea> does not have a scrollbar any more, you need to scroll the window. This would make the right side disappear.

Change 471724 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/TwoColConflict@master] Limit <textarea> to available window size, when it makes sense

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

@Hanna_Petruschat_WMDE Do you have an opinion? To me the third option (available window size only as a limit when editing the larger size) sounds like the best one for now. So it is possible for you to find out that the smaller area is not going beyond the fold then?
Solution one (synchronizing both) seems rather prone to many more difficult situations.

I have two remarks:
1. solution
From earlier discussions I thought this would not be possible. So I'm confused. Do I understand it right, that simultanious scrolling of two boxes without scrolling the whole window is indeed doable? And if so: I do not really see a huge benefit against keeping the original heights. Also: see comment to solution 2. What happens if there are changes in the beginning and the end of the paragraph. Will they be hidden then?

2. solution
This might be my favorite as there might be the least potential for edge casy bugs. e.g. What happens if there are two changes in a paragraph, one in the beginning, on in the end? How would you highlight the text and make the user aware of the differences in a scroll box?

3. solution
I honestly do not fully understand this approach. What happens if both boxes are larger than the window? The editable and larger box will then be shortened, the other one will remain its size so the user might need to scroll to see the complete "shorter" box which is still larger then the window size?

I think we need to demo and talk about this in person, as the conversation here gets really confusing.

it is possible for you to find out that the smaller area is not going beyond the fold then?

Sorry, the suggestion was not about the fold. Let me try again: The side the user is currently editing grows at least as high as the non-editable side (this doesn't care about the fold, both sides can be larger than the window). This is critical to be able to see both sides and have them in sync when scrolling. Only if the non-editable side is smaller than the window, but the editable side contains much more text, the editor is limited to the window height.

Do I understand it right, that simultanious scrolling of two boxes without scrolling the whole window is indeed doable?

I don't see why it wouldn't be possible: https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollTop. That's why I mentioned it. However, going this route does potentially have many implications and will cost us an amount of UX and dev time that's not worth it, in my opinion.

Change 471724 merged by jenkins-bot:
[mediawiki/extensions/TwoColConflict@master] Limit <textarea> to available window size, when it makes sense

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

Change 471990 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/TwoColConflict@master] Simplify <textarea> height calculation a lot

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

Change 471990 merged by jenkins-bot:
[mediawiki/extensions/TwoColConflict@master] Simplify <textarea> height calculation a lot

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