XWIKI-24755: XClass properties can only be reordered with a mouse in the class editor

[Sereza5]

Jira URL

https://jira.xwiki.org/browse/XWIKI-24755

Changes

Description

• New reorderControls widget (uicomponents/widgets/reorderControls.js, registered as xwiki-reorder-controls), adding a move up and a move down <button> to each item of a list. A button moves its item on a click or tap and on the up and down arrow keys, keeps the focus so moves can be chained, and announces the new position in a shared polite live region.
• The class editor uses the widget in place of the non-focusable <span class="tool move"> drag handle. The widget's onMove callback persists the change, so drag and drop and the buttons both end up in the existing updateOrder() and the hidden Number field stays in sync.
• Each button gets a screen-reader-only name and a tooltip naming its property (Move property <name> up), mirroring the delete tool.
• The buttons' default border and padding are reset so the three tools align, and the tools container gets 3px of right padding, since its overflow: hidden was clipping the last tool's focus indicator.
• core.editors.class.moveProperty.handle.label is deprecated in place, and the four moveProperty.up/down.text/tooltip keys are added.

Clarifications

• Two buttons rather than one keyboard-operable handle. A handle answering the arrow keys closes SC 2.1.1 Keyboard but not SC 2.5.7 Dragging Movements, which the issue also cites: keyboard equivalence only meets it if the equivalent operation "also provides controls that can be clicked or tapped with a pointer". Two clickable buttons satisfy both; the arrow keys stay as a convenience.
• The buttons are not drag handles. jQuery UI sortable keeps its default cancel, which excludes buttons, so an imprecise tap can never become a drag, which would defeat the point for the users SC 2.5.7 protects. Dragging still works from the property title, where ClassEditPage.movePropertyBefore now starts it.
• The widget is meant to be reused. The dashboard gadgets (uicomponents/dashboard/dashboard.js) are still pointer-only and the natural next consumer. The object editor would follow once XWIKI-5671 has a persistence model, which is out of scope here: an xobject's number is its reference and oldcore has no renumber API, so it needs a design decision first.
• Live Data column headers keep their own Vue implementation (keyboardDragNDrop(), XWIKI-21009); this widget targets plain DOM lists. The Number meta-property stays hidden, since the order is now operable without it.
• One gap left out on purpose: at 16x16 the tools are below the 24x24 of SC 2.5.8 Target Size (Minimum). That size is pre-existing and shared with the delete tool, so enlarging only the new buttons would break the row's alignment. Filed separately.

Screenshots & Video

Before	After

The actions of a property title, on a class holding three properties: the delete link with the single drag handle, then the delete link with the two move buttons.

Executed Tests

Built the changes with:

• mvn clean install -Plegacy,integration-tests,quality on xwiki-platform-web-war, xwiki-platform-flamingo-skin-resources and xwiki-platform-test-ui -- BUILD SUCCESS, 0 Checkstyle violations.
• mvn checkstyle:check@default checkstyle:check@test -Pdocker,integration-tests on xwiki-platform-flamingo-skin-test-docker -- 0 violations on both rulesets.
• mvn test-compile -Plegacy,docker,integration-tests on the same module -- BUILD SUCCESS.

Then tested them with:

• mvn verify -Pdocker,integration-tests,legacy -pl <flamingo-skin-test-docker> -Dxwiki.test.ui.servletEngine=tomcat -Dxwiki.test.ui.database=postgresql -Dit.test='EditClassIT#reorderProperty+reorderPropertyWithoutDragging' -- 2/2 tests pass.
  • reorderPropertyWithoutDragging is new: both controls are button elements with the expected screen-reader name and tooltip, a click moves the property up and down and leaves the focus on the button, the first property cannot move up and the last cannot move down, the arrow keys work on both buttons, and the new order survives a save and reload.
  • reorderProperty is the pre-existing drag and drop test, kept green now that the handle is gone and the drag starts from the property title.
• Checked on the running instance that the three tools share a baseline and that the move buttons' focus indicator renders unclipped, which is what the 3px of right padding fixes.

Expected merging strategy

• Prefers squash: Yes
• Backport on branches: none -- this changes the DOM of an editor and adds translation keys, so it is better left on master.

[Sereza5]

Started a forum post at https://forum.xwiki.org/t/proposal-move-up-move-down-buttons-in-the-class-editor/18809 to discuss the changes proposed here, since it impacts the UI in a meaningful way.

[Sereza5]

Pushed b7c07bb implementing the feedback from the forum proposal.

What changed

• The property title now uses cursor: grab, and the sortable switches it to grabbing while a property is being
  dragged. This is the +4 answer to mleduc's point that dropping the handle also drops the only hint that a property
  can be dragged: the cursor covers the whole area that actually accepts the drag instead of pointing at one 16x16
  icon. Drag and drop itself is unchanged, as mflorea asked.
• The title got a bit of vertical padding, so the band you can start the drag from is comfortable even though the
  title is a single line of text.
• The move and delete tools keep cursor: pointer, since they are the one spot where a drag cannot start.
• Live Data, following mleduc's remark that only a very small part of the column headers had a grab cursor: the
  cursor moved from the inner button to the whole .column-name, which is the element vuedraggable actually uses as
  the drag handle, and the cursor: pointer island on the sort icon was removed. The whole header now reads as one
  draggable zone.

Tests

• mvn clean install -B -ntp -Plegacy -pl xwiki-platform-core/xwiki-platform-web/xwiki-platform-web-war: builds
  clean, jshint, Checkstyle and Revapi pass.
• mvn clean install -B -ntp -Plegacy -pl xwiki-platform-core/xwiki-platform-node: the Vue sources build and
  @xwiki/platform-livedata-ui passes its 114 unit tests, 0 failures.
• Manually checked on a local 18.8.0-SNAPSHOT instance: hovering a property title shows the grab cursor, dragging it
  shows the grabbing one, hovering either move button or the delete button shows the pointer, and a Live Data column
  header shows the grab cursor over its full width instead of only over the property name.

Worth noting for whoever runs the node build: @xwiki/platform-editors-blocknote-react:test fails on master
independently of this PR, its Playwright component test imports LinkEditionHandler and SyntaxConfig as values
while both are exported as types.

Left to do: one last check with the skill xwiki-review to make sure the latest changes do not bring problems.