Screen (browser) jumps after editing an entity

Support
#1

Currently our application (Cuba 7.2.15) has developed a problem with browse screens, that use StandardLookup. When a customer has added many rows of data an odd browsing bug occurs. After they finish editing an entity (represented by selecting 1 row) the screen will jump down.

The more data a table contains the further away the screen will jump, often completely to the bottom. This has the effect that users can no longer track what the change was they had just made. They need to scroll upwards to find the row they selected. This is very tedious to experienced users and a source of frustration to our novice users.

While searching the Cuba Forum I did come across a potential solution. ‘Sparsh’ reported on a similar issue when using groupBox in his post ‘Screen issue on group box expansion’. The solution that was offered was to place groupBox inside of a scrollBox tag. I am pleased to report that works for us as well, but with consequences.

As we are using a groupTable the header bar with the column names scrolls out of view. As the tables may contain hundreds of rows this becomes problematic. We can create a sticky header bar but this creates new issues:

  • The header does not scroll horizontally when scrolling the table in that direction
  • The header is not sized to the available table width (instead it just uses its full required width)
  • The header buttons to select columns and save presentations might disappear from view as well (if the header is wider than the browser window)

For illustrative purposes I have added two screenshots.

In the first the user selects row 3 with the title ‘Terms and definitions’. They hit the Edit button or double click the row to edit. In the pop-up window they will make the necessary changes and then hit the Save button.

GroupTable_example
GroupTable_example1196×600 64.9 KB

Immediately they are confronted with the screen having jumped down, with the row they selected having moved out of view.

GroupTable_example_2
GroupTable_example_21212×539 58.1 KB

1 Like
#3

Hello!

I’ve tried to reproduce this case but with no success. Could you share a screen Java controller and its XML descriptor (without a fix with scrollbox tag)? Or better, share a small demo project that reproduces the issue.

#5

Hello Roman,

I have managed to narrow down the problem, reproducing it should now be easy.

The issue of the screen jumping after editing a row occurs when the XML descriptor contains the attribute and value forceDialog=“true” as part of the dialogMode.

Using the Cuba Platform example ‘sample-sales-cuba7’ I could easily recreate the issue:

  1. Add forceDialog=“true” to dialogMode in product-edit.xml
  2. Start the application, create about 60 entities
  3. Set ‘Show rows’ to 100
  4. Scroll down so row 50 is the last in view, that leaves about 15 outside of view
  5. Select row 30, click ‘Edit’ and in the pop-up screen click ‘OK’.

For me the screen has jumped 9 rows. Row 30 is not at the top, but close to it and there are still a bunch of rows at the bottom of the table out of view. So I cannot discern a pattern.

Next I tried to prove the opposite. In our application I altered one entity and set its XML descriptor to forceDialog=“false” and the problem goes away. However, we are very keen on keeping our Edit pop-up.

I am hoping a solution can be found for this bug.

#7

Thank you for the reproducing scenario. I’ve create an issue: cuba-platform/cuba#3244.

For now, as a workaround I can suggest you scroll to the selected entity:

@Named("productsTable.edit")
private EditAction<Product> productsTableEdit;
@Inject
private GroupTable<Product> productsTable;

@Subscribe
public void onInit(InitEvent event) {
    productsTableEdit.setAfterCloseHandler(afterCloseEvent -> {
        Product product = productsTable.getSingleSelected();
        if (product != null) {
            productsTable.scrollTo(product);
        }
    });
}
#9

Hi @Pinyazhin

I’ve tried your suggestion but it does not really solve the problem. Although the table is scrolled to a more nearby row, the rows are still scrolling out of view and the usability is hardly improved.

Do you have any plans to put some effort in solving this issue?

Regards,
-b