@Insertcleverphrasehere: Adding PageTriage project tag so this task can be found when looking at PageCuration tasks at https://phabricator.wikimedia.org/tag/mediawiki-extensions-pagecuration/ . No need to add team tags like Growth-Team; that is up to each team (or automatic filters).

Change 507455 had a related patch set uploaded (by MusikAnimal; owner: MusikAnimal):
[mediawiki/extensions/PageTriage@master] Enlarge 'mark as approved' textarea, and auto-resize all textareas

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

Change the height of the panels to ... not be more than 70% of the viewport height

This turned out to be pretty complicated. While probably doable, there are other situations this wouldn't cover such as moving around the toolbar or resizing the window itself. I don't think it's worth it -- from both an engineering and performance standpoint -- to have all those complicated page-wide event listeners for just resizing textareas. The issue is not unique to "Mark as reviewed" anyway; the "Add tags" flyout for instance also can extend beyond the viewport.

Instead I've done two things (to be reviewed):

• Increased the width of the "Mark as reviewed" textarea to be about the same as the other textareas. This alone will probably provide enough room for most messages, without needing to resize the textarea.
• Auto-resize up until a max of 12 lines of text.

Note that the textarea does not get smaller if you were to remove lines of text. This is a caveat of the implementation, but I think that's okay... The user can still manually resize the textarea as desired.

I've got this up on CommTechWiki if anyone wants to play with it, e.g. try this article: https://commtech.wmflabs.org/wiki/Dafdsfadf

@MusikAnimal Is there a reason we don't want to allow the textarea to be resizable beyond 12 lines of text? I think we could go a bit higher - maybe 20?

Part of the request on the project page is to make more content in the Add tags and Mark for deletion tabs visible without needing to scroll. If we can't do 70% viewport height, should we instead make the tabs longer by default?

In T207439#5151534, @Niharika wrote:

@MusikAnimal Is there a reason we don't want to allow the textarea to be resizable beyond 12 lines of text? I think we could go a bit higher - maybe 20?

It's completely arbitrary, I was just trying to find a sensible limit. On my screen, 12 is quite a bit. There's also the textareas in the tag flyout, and that flyout is much larger than the "Mark as reviewed" flyout. We'd need some complicated JS to not expand the textarea beyond the viewport. Otherwise it's possible it'll go so far beyond the viewport that they can't reach the submit button, even if they move the toolbar around.

Part of the request on the project page is to make more content in the Add tags and Mark for deletion tabs visible without needing to scroll. If we can't do 70% viewport height, should we instead make the tabs longer by default?

All of this is awfully tricky... One thing I can say is we do need JS to get a true 70% height of the viewport. Increasing the general height by default (using CSS) isn't safe, because the viewport may not be that big. The whole toolbar thing uses fixed positioning, so I don't think we can use percentages relative to the viewport. And again, the textareas expand, so the situation where you can't reach the submit button, and are forced to hit refresh and start all over again, is very possible.

I'm not sure what to do! :(

@MusikAnimal Okay, let's go with changing the textarea to auto-resize to max 12 lines, like you said, for now. Based on what we hear from users, we can look back into this. So I will temporarily remove the part (b) of the requirements.

let's go with changing the textarea to auto-resize to max 12 lines, like you said, for now. Based on what we hear from users, we can look back into this. So I will temporarily remove the part (b) of the requirements.

Sounds good. Like I said between the widened "mark as approved" textarea, and the auto-expanding, there's a lot more room then there was. An improvement, I hope :) As for part (b), I think it just so happens everyone who asked for this has a larger screen.

This is now ready for code review.

Change 507455 merged by jenkins-bot:
[mediawiki/extensions/PageTriage@master] Enlarge 'mark as approved' textarea, and auto-resize all textareas

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

Note for QA: In this iteration, I only changed the textareas auto-resize to a max of 12 lines. No other logic beyond that; the auto-resizing does not stop if it exceeds the viewport.

In T207439#5237606, @MusikAnimal wrote:

Note for QA: In this iteration, I only changed the textareas auto-resize to a max of 12 lines. No other logic beyond that; the auto-resizing does not stop if it exceeds the viewport.

I tested this on "Mark as review", "Add tags" and "Mark for deletion" in the Page Curation toolbar, on Firefox 60 and Safari 10.

I noticed that the text areas do not auto-resize when I copy and paste multiple lines of text into them. They remain their original size (even if I start to type more text) and I have to click and drag to make the text area bigger.

This occurs on Firefox, Chromium and IE11, but not Safari (which does auto-resize). Perhaps this is just a cross-browser difference we cannot control. I am not sure if it is a major problem.

In T207439#5240906, @dom_walden wrote:

In T207439#5237606, @MusikAnimal wrote:

Note for QA: In this iteration, I only changed the textareas auto-resize to a max of 12 lines. No other logic beyond that; the auto-resizing does not stop if it exceeds the viewport.

I tested this on "Mark as review", "Add tags" and "Mark for deletion" in the Page Curation toolbar, on Firefox 60 and Safari 10.

I noticed that the text areas do not auto-resize when I copy and paste multiple lines of text into them. They remain their original size (even if I start to type more text) and I have to click and drag to make the text area bigger.

This occurs on Firefox, Chromium and IE11, but not Safari (which does auto-resize). Perhaps this is just a cross-browser difference we cannot control. I am not sure if it is a major problem.

@dom_walden Good catch! @MusikAnimal Can we fix that?

In T207439#5241376, @Niharika wrote:

In T207439#5240906, @dom_walden wrote:

I tested this on "Mark as review", "Add tags" and "Mark for deletion" in the Page Curation toolbar, on Firefox 60 and Safari 10.

I noticed that the text areas do not auto-resize when I copy and paste multiple lines of text into them. They remain their original size (even if I start to type more text) and I have to click and drag to make the text area bigger.

This occurs on Firefox, Chromium and IE11, but not Safari (which does auto-resize). Perhaps this is just a cross-browser difference we cannot control. I am not sure if it is a major problem.

@dom_walden Good catch! @MusikAnimal Can we fix that?

I was not able to reproduce this problem. I tried in Firefox and Chromium. Could someone else confirm?

In T207439#5260007, @MusikAnimal wrote:

I was not able to reproduce this problem. I tried in Firefox and Chromium. Could someone else confirm?

Looking into this, it only happens if you copy and paste a large enough body of text.

On Firefox, about 500 characters in one paragraph or over 10 separate lines of text. More or less on other browsers.

I haven't been able to work out what the typical length of a comment/message is on this tool.

Change 517720 had a related patch set uploaded (by MusikAnimal; owner: MusikAnimal):
[mediawiki/extensions/PageTriage@master] Fix setting of height when pasting in text into textareas

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

Finally figured it out. Careless error, simple fix: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PageTriage/+/517720

Thanks for noticing it, Dom!

Change 517720 merged by jenkins-bot:
[mediawiki/extensions/PageTriage@master] Fix setting of height when pasting in text into textareas

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

Retested briefly on beta with Firefox, Safari and IE11. This looks fine.