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

Clicking any row in a TreeTable causes immediate scrolling to top of table #3091

Closed
vaadin-bot opened this issue Oct 31, 2012 · 23 comments
Closed

Comments

@vaadin-bot
Copy link
Collaborator

Originally by archie172


This is a relatively new problem present in 7.0.0.beta6.

I have a TreeTable and it contains more rows than can be displayed in its height, and therefore it has a vertical scroll bar.

If I click on (i.e., select) any row in the table, the table immediately scrolls to the top.

Of course, to notice this effect you have to scroll down first, so that the scroll bars start out not at the top.

As soon as you click on a row, the table is scrolled to the top row. This is especially annoying when the row that you clicked on is way down at the bottom: as soon as you click on it, it is no longer visible in the scroll window and you have to scroll back down again to see it.


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

@vaadin-bot
Copy link
Collaborator Author

Originally by archie172


More info on this issue. In my application when you click on a row, underneath the Table (in the same VerticalLayout) I present the details of that item.

It appears that it is actually the modification of the details pane that is causing the jump to the first row, not the clicking on the Table row.

I know this because in the details pane there is a Cancel button that causes it to reset (i.e., remove and replace) the details pane. When I click this Cancel button, the same problem occurs.

So it's not the clicking of the Table row that causes the problem; the clicking of the Table row is triggering the problem in my particular application.

Instead, it is the replacement of an unrelated, subsequent component in the VerticalLayout containing the Table that causes the Table to jump to the first row.

@vaadin-bot
Copy link
Collaborator Author

Originally by archie172


FYI problem also occurs in 7.0.0.beta7.

@vaadin-bot
Copy link
Collaborator Author

Originally by archie172


One more interesting fact: if the Table has enough rows, and the row you click on is near the bottom of the table, then when the Table jumps to the top row, the entire view of what should be the top few rows of table content is just completely blank.

It is as if the Table doesn't even know that it is displaying those rows, and because they have fallen out of its client-side cache, they appear completely blank.

Then, as soon as you bump the mouse scroll wheel one bump downward, the rows suddenly appear.

@vaadin-bot
Copy link
Collaborator Author

Originally by @jdahlstrom


I'll take a look.

@vaadin-bot
Copy link
Collaborator Author

Originally by @jdahlstrom


Seems to manifest with both Table and TreeTable when the parent layout is changed (components added/removed) and the layout is setSizeFull().

@vaadin-bot
Copy link
Collaborator Author

Originally by @jdahlstrom


Actually, it appears this is already fixed in the current master.

@vaadin-bot
Copy link
Collaborator Author

Originally by archie172


Problem still occurs in 7.0.0.beta8.

Can you indicate the commit in the master branch that fixes this problem?

Thanks.

@vaadin-bot
Copy link
Collaborator Author

Originally by @jdahlstrom


I was able to reproduce it earlier today but not after I pulled the newest changes. I assumed 2d77a271 might have fixed this issue as a side effect, but will take a closer look on Monday.

@vaadin-bot
Copy link
Collaborator Author

Originally by archie172


OK, I tried applying that patch and it didn't fix the problem for me, but I may have done something wrong.

Not a big deal.. I can (and will) wait for 7.0.0.beta9 to verify that it's fixed.

@vaadin-bot
Copy link
Collaborator Author

Originally by @jdahlstrom


Hmm... Now I cannot reproduce this even with beta8 or beta7. Could you provide a test case?

@vaadin-bot
Copy link
Collaborator Author

Originally by archie172


Gladly. See attached.

@vaadin-bot
Copy link
Collaborator Author

Originally by archie172


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

@vaadin-bot
Copy link
Collaborator Author

Originally by @jdahlstrom


Thanks. Yes, I can reproduce this. Will investigate.

@vaadin-bot
Copy link
Collaborator Author

Originally by @Artur-


This is likely related to layouts adding an extra DOM level when needed for expand ratios. The Table will then be detached and re-attached to the DOM, causing the scroll position to be lost.

@vaadin-bot
Copy link
Collaborator Author

vaadin-bot commented Jan 14, 2013

Originally by @johndevs


I cannot reproduce this with the demo3.war provided in any major browser with the latest trunk.

As Artur states this issue was probably related to the attaching/detaching of the expand element in a VerticalLayout which caused the Table to get refocused and thus scroll up. The VerticalLayout was fixed in this regard along with https://dev.vaadin.com/ticket/10161 so this does not happen anymore and probably fixed this issue as well.

If you still are experiencing this with Vaadin 7 RC1 then please reopen the ticket.

@vaadin-bot
Copy link
Collaborator Author

vaadin-bot commented Jan 14, 2013

Originally by @Legioth


#3291 shows that the issue can still be reproduced in some specific situations and that the problem is indeed caused by the VerticalLayout temporarily detaching the element from the DOM that https://dev.vaadin.com/ticket/10161 changed to only occur in some specific situations.

@vaadin-bot
Copy link
Collaborator Author

Originally by @joheriks


Attachment added: TreeTableScrollPositionBugExposure.war (10560.5 KiB)

@vaadin-bot
Copy link
Collaborator Author

Originally by @joheriks


We found that the same (or a very closely related) issue can be evoked in 7.1.11 under the following circumstances. A VerticalLayout contains a TextField and a TreeTable (in that order). The TreeTable has some hierarchical elements and is long enough to be scrollable. The TreeTable is selectable and is in immediate mode, and furthermore its valuechange-listener updates the value of the TextField. When the user has scrolled down to the bottom of the treetable and selects a row (e.g. the last row), the scroll position jumps close to the top, obscuring the currently selected row.

A minimal application exposing the bug is attached.

Observations:

  • The bug was perceived to be elusive and hard to reproduce. It seems to work better for some number of rows and/or component heights.
  • Wrapping the TextField in e.g. a HorizontalLayout is a workaround

@vaadin-bot
Copy link
Collaborator Author

Originally by Juuso Valli


The bug mentioned in comment 24 is only sort of related to the original reported bug.

During layout recalculation the TextField temporarily lost it's height and margin, which caused the Table to resize. This was fixed in a coincidental second pass of the layout calculation, but the double resize of the Table moved the scroll position.

@vaadin-bot
Copy link
Collaborator Author

Originally by @Saulis


Fix causing regression in:
VerticalSplitPanel* tests on IE8
HorizontalSplitPanel* tests on IE8

@vaadin-bot
Copy link
Collaborator Author

Originally by CodingFabian


i still observe this behaviour. its not always jumping to the top, but i assume it is related to row caching. if i have a long table and for example select every second item, as soon as a few selected items have scrolled out, a selection can lead to the table jumping up. (7.2.4)

@vaadin-bot
Copy link
Collaborator Author

vaadin-bot commented Jul 18, 2014

Originally by CodingFabian


sry, it was caused by #4895 which I did not merge correctly.
all is fine!

@vaadin-bot
Copy link
Collaborator Author

Originally by Juuso Valli


That's good to hear :)

@vaadin-bot vaadin-bot added the bug label Dec 9, 2016
@vaadin-bot vaadin-bot added this to the Vaadin 7.2.2 milestone 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