Does there need to be anything displayed in the draggable areas, or is it enough to change the cursor to an updown arrow icon?

I think ideally there would be an affordance there. Usually it looks like a few (1-3) parallel lines or some dots.

Change 701726 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/ProofreadPage@master] Add vertical resize handle to page edit form

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

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

https://patchdemo.wmflabs.org/wikis/478497b5be/w/

The above patch can be seen in action at e.g. https://patchdemo.wmflabs.org/wikis/478497b5be/w/index.php?title=Page:Test.pdf/1&action=edit

1. In Safari 14.1.1 the resizing is wonky: when the mouse hits the edge of the window it starts to select text (but keeps resizing).
2. Lack of independent resizeability for the header and footer also looks likely to feel constricting. Their optimum size depend on a) their contents, and b) what the user is currently doing (when editing them or trying to see what they contain, they would optimally be large; when done with them and working on the main text they should be small and out of the way). Sizing them relative to the height of the main text field is never going to be optimal; but it may be "good enough".
3. In Google Chrome (recentish) when logged out the default height was very tall, and the header and footer fields consequently oversized.
4. Firefox/Safari/Chrome/Vivaldi: Dragging to the edge of the window behaves inconsistently: sometimes stopping, sometimes scrolling the page.
5. Firefox/Safari/Chrome/Vivaldi: The fields appear to have a minimum height and when you drag beyond that the MW chrome (edit summary etc.) starts to overlap the PRP text fields and page image.
6. Firefox (recentish) logged out has same initial rendering as Chrome (surprisingly tall, oversized header/footer).
7. Firefox/Safari/Chrome/Vivaldi: You also can't resize beyond the inherent (as loaded) page height.

Switching to vertical layout and then back to horizontal is borked now too: half the MW edit chrome is missing (hidden behind) and the image extends beyond its container; but the edit summary text field is visible above (presumably due to its z-index).

At a wild guess this is PRP resetting image zoom when the switch happens and overwriting some of the new (flex-based) styles. I'm thinking that because there was a previous (otherwise unrelated) bug with image zoom where I seem to recall the fix involved adding another call to the image zoom initializer function. I could be way off though.

Sorry about the slow progress here. I'm still working on ironing out all the edge cases.

I wonder if it's worth rolling back the flexbox changes for the time being? Or setting a max-height on the form (to fix the issue of not being able to use the toolbar in the footer)? Then following up with proper resize functionality.

In T285529#7199624, @Samwilson wrote:

I wonder if it's worth rolling back the flexbox changes for the time being?

I'm not seeing massive pushback like that for the previous Flexbox attempt. The changes right now seem to be impacting negatively a relatively low number of users with workflows that diverges from the majority (essentially anyone using the alternate/horizontal layout), but for now they appear to be content with either living with it until fixed or are using CSS-based workarounds.

It is possible there is frustration in non-English projects that I'm not picking up, but I would expect significant such to find its way to mulWS eventually (cf. the reports from plWS) and that's not been the case so far.

IOW, based on what I'm seeing I don't think rollback is necessary as of now.

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

https://patchdemo.wmflabs.org/wikis/478497b5be/w/