Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Table scroll position jumps to top after item set change event #3727

Closed
vaadin-bot opened this issue Mar 30, 2013 · 9 comments
Closed

Table scroll position jumps to top after item set change event #3727

vaadin-bot opened this issue Mar 30, 2013 · 9 comments
Labels

Comments

@vaadin-bot
Copy link
Collaborator

Originally by archie172


I have a Table that is backed by an indexed Container which contains data of an unknown size (actually the data size is known but expensive to calculate).

So the Container automatically grows in size when an item near the end of the container is accessed (specifically, past the 85% mark), causing an item set change event to be generated.

The above information is just to motivate this example and explain the attached test case.

The actual problem is: if the Table receives an item set change event while the scroll bar is being positioned, the scroll position is lost and the scroll bar jumps back up to near the top of the table.

This problem is not specific to this "auto-growing" Container example. I have seen it in other situations as well.

The problem seems to occur any time item set change events can be generated while scrolling a Table. Since when the user might want to scroll is unpredictable, this problem applies to any Table connected to a Container that spontaneously generates item set change events, e.g., perhaps reflecting some server-side process that is being monitored.

Having a Table show a real-time view of some information is a very common GUI task. For example, imagine a twitter feed, stock ticker, etc., showing the most recent event on top.

If scrolling through the Table is disrupted every time there is a new item added to the Table, this is obviously a major annoyance. It becomes more than just an annoyance however, and especially frustrating, when the Table contains a large number of rows, because not only do you lose your place in the list and have to start over, but because it takes some time to scroll back down again to find where you were before, another update comes in and the problem occurs again, etc. So you are effectively "locked out" from viewing anything but the top part of the Table because you can never get there in time.

How to reproduce this problem:

  1. Fire up the attached test case (demo3.war)
  2. Grab the scroll bar and smoothly drag it to the bottom
  3. The Table will resize, but the scroll bar jumps back up near the top

Possibly related: #10106


Imported from https://dev.vaadin.com/ issue #11454

@vaadin-bot
Copy link
Collaborator Author

Originally by archie172


Attachment added: demo3.war (9216.3 KiB)
WAR file exhibiting the problem

@vaadin-bot
Copy link
Collaborator Author

Originally by @Artur-


This sounds very similar to fixes done in 6.8.x some months ago but these have been merged to 7.0.3 already. Needs to be investigated if this can be fixed properly in the current Table implementation.

@vaadin-bot
Copy link
Collaborator Author

Originally by archie172


Looks like I forgot to set the issue priority. Setting to normal.

@vaadin-bot
Copy link
Collaborator Author

Originally by piotr


I have been having this problem as well. Would be more than happy if you could fix it asap.

@vaadin-bot
Copy link
Collaborator Author

Originally by piotr


This appears to be fixed in 7.0.6?

@vaadin-bot
Copy link
Collaborator Author

Originally by @hesara


This is still reproducible with Vaadin 7.0.6 with a simplified version of the demo application.

@vaadin-bot
Copy link
Collaborator Author

Originally by @hesara


Investigating this further, the issue seems to depend on at which point the item set is changed during request processing. It is not completely clear yet if the test WAR modifies the container size early enough in request processing or only in the paint phase, where the container should not be modified.

An example of an application that does not exhibit the problem as it makes sure the container is expanded before the table is otherwise painted:

public class HelloUI extends UI {

    @Override
    public void init(VaadinRequest request) {
        final VerticalLayout rootLayout = new VerticalLayout();

        rootLayout.setSizeFull();
        rootLayout.setMargin(true);

        final SimpleExpandingContainer container = new SimpleExpandingContainer();

        Table table = new Table(null, container) {
            @Override
            public void changeVariables(Object source,
                    Map<String, Object> variables) {
                if (variables.containsKey("firstvisible")) {
                    int index = (Integer) variables.get("firstvisible");
                    container.checkExpand(index);
                }
                if (variables.containsKey("reqfirstrow")
                        || variables.containsKey("reqrows")) {
                    try {
                        int index = ((Integer) variables
                                .get("lastToBeRendered")).intValue();
                        container.checkExpand(index);
                    } catch (Exception e) {
                        // do nothing
                    }
                }
                super.changeVariables(source, variables);
            }
        };
        table.setSizeFull();
        table.setVisibleColumns(new String[] { "name" });
        rootLayout.addComponent(table);

        setContent(rootLayout);
    }

    /**
     - Simple auto-expanding container for testing - very inefficient.
     -/
    public static class SimpleExpandingContainer extends IndexedContainer {
        public SimpleExpandingContainer() {
            addContainerProperty("name", String.class, "");
            checkExpand(200);
        }

        public void checkExpand(int index) {
            int size = size();
            if (index >= size * 0.75) {
                int newSize = Math.max(index, (int) (size * 1.33));
                for (int i = size; i < newSize; ++i) {
                    String id = "Item " + i;
                    Item item = addItem(id);
                    item.getItemProperty("name").setValue(id);
                }
            }
        }
    }
}

@vaadin-bot
Copy link
Collaborator Author

@vaadin-bot
Copy link
Collaborator Author

Originally by T-Gergely


Replying to Kronqvist:

Fixed in https://dev.vaadin.com/review/gitweb?p=vaadin.git;a=commit;h=407bdb39f7d87acaf15c399e46baf6d6a858fa6d

This introduced a new bug: http://dev.vaadin.com/ticket/13338#comment:2

@vaadin-bot vaadin-bot added the bug label Dec 9, 2016
@TatuLund TatuLund added the v7 label Mar 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants