Page MenuHomePhabricator

Add resize handles to textareas
Open, Needs TriagePublic


After T285128 it would now be good to be able to resize the three textareas, as well as the whole form (image and textareas). To do this, we could add draggable resize handles to the spaces between the textareas and to an area below the whole form. The sizes should be remembered in localstorage, so that they don't need to be reset every time and can also be different for different devices for the same user.

draggable-divider.png (265×677 px, 7 KB)

Event Timeline

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

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

  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.

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.