XWIKI-17296: Inconsistent dropdown behaviour between object and class editor

[Sereza7]

Jira URL

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

Changes

Description

• Fixed the default state of the dropdown.
• Fixed a couple small usability bugs on the user path described in the ticket description. See clarification for details.

Clarifications

• I updated the signature of expandCollapseMetaProperty in a way that would keep backwards compatibility. When providing only the first argument, the result of this function is the same as it was.
• When there was no name set for the property it would submit the edit form and open the preview of the doc?? AFAIU the type on this button should have been button (action unrelated to the form) instead of submit (the button purpose is to submit the form -- here the edition of the page). (fix on editclass.vm L143) Note that hiting the Enter key on the input still submits the edition form... Since it's not the main concern of the ticket, I'm not providing further solution for this problem here.
• When the user clicked on the reordering handle (blue "move" icon), the description of the field would expand or collapse, making it significantly more difficult to reorder fields here. (fix on dataeditors.js L697)

Screenshots & Video

Here is a video demo of my local instance with the PR applied. Everything mentionned above and in the ticket description behaves as expected.

2025-12-01.16-16-37.mp4

Executed Tests

Manual tests, see video above.
Checked the updated files with SonarQube, no new codestyle/quality violation.
Successfully built the quality profiles of modules with changes:

• mvn clean install -f xwiki-platform-core/xwiki-platform-web/xwiki-platform-web-war/ -Pquality
• mvn clean install -f xwiki-platform-core/xwiki-platform-flamingo/xwiki-platform-flamingo-skin/xwiki-platform-flamingo-skin-resources -Pquality

Successfully passed docker tests mvn clean install -f xwiki-platform-core/xwiki-platform-flamingo/xwiki-platform-flamingo-skin/xwiki-platform-flamingo-skin-test/xwiki-platform-flamingo-skin-test-docker, which contains EditClassIT that use the ClassEditPage object. (I tried to use a pattern but didn't get it to work so it just ran all the flamingo tests in about 25 minutes).

Expected merging strategy

• Prefers squash: Yes
• Backport on branches:
  • 17.10.X . The scope of the change is well defined and the changes are pretty limited.

[Sereza7]

I just went to double check docker tests. They don't fail despite the change in the initial state because:

• They used to expand the panel whenever creating a new property in a class.

  xwiki-platform/xwiki-platform-core/xwiki-platform-test/xwiki-platform-test-ui/src/main/java/org/xwiki/test/ui/po/editor/ClassEditPage.java

  Line 167 in adc4051

  return new ClassPropertyEditPane(getForm(), propertyName).expand();

• The expand function contains a logic gate to only click if the panel is not expanded :)

  xwiki-platform/xwiki-platform-core/xwiki-platform-test/xwiki-platform-test-ui/src/main/java/org/xwiki/test/ui/po/editor/ClassPropertyEditPane.java

  Lines 66 to 67 in c0c4cde

  	if (getDriver().findElementWithoutWaiting(containerLocator).getAttribute("class").contains("collapsed")) {
  	getDriver().findElementWithoutWaiting(titleLocator).click();

Technically the expand function could be removed. Leaving it, because it doesn't hurt and I don't want to run all the flamingo tests again just to make sure removing it is not a regression...

[github-actions]

💚 All backports created successfully

Status	Branch	Result
✅	stable-17.10.x

Questions ?

Please refer to the Backport tool documentation and see the Github Action logs for details