Table row sometimes covered up by scrollbars

This has been a periodic, but ongoing issue and I thought I’d see if anybody at Vaadin or the community has seen it and resolved it.

I have a Table that lists rows that can be clicked on to open up additional information. Most of the time, it looks fine, and it rarely has problems when the browser is maximized on an HD monitor. As the video below shows, I can switch objects that will show 1 page, 2 pages, 3 pages and 4 pages (each page info is shown in the Table) and they all will look fine, but every now and again, scrollbars will appears and hide the bottom row.

What is also odd is that when I tried to record this problem using Camtasia, it never occurred. So I recorded on my phone, and when the bug/issue is present, just starting Camtasia recording caused the scrollbars to disappear in the browser with my clicking or doing anything else.

Here is a YouTube video
( of my screen that shows it happening on an up-to-date Chrome browser running Vaadin 7.2.3.

The basic Table setup code looks like this:

            pageInfoContainer = new PageInfoContainer();
            setVisibleColumns( (Object[])vaadinUi.getStringArray("pageNumber;pageName;editReviewType;deleteButton") );
            setColumnHeaders( vaadinUi.getStringArray("Order;Page EsfName;Mode; ;") );
            setColumnAlignment("pageNumber", Align.CENTER);
            setColumnExpandRatio("pageName", 0.5f);
            setColumnExpandRatio("editReviewType", 0.3f);
            setColumnExpandRatio("deleteButton", 0.2f);

And when I set the data elements to populate the table, I set the page size to be the number of rows in the container:

pageInfoList.setPageLength( pageInfoContainer.size() );

What might cause this? I have tried ?debug and analyze layouts, and it shows nothing. The only “solution” I’ve found is to always set the Table.setPageLength to be 1 bigger than my container size so that the scrollbars, when they do appear, cover a blank row. But it looks ugly to always have an extra blank row since most of the time the errant scrollars will not appear.

Hope someone can help as it’s particularly bad when it occurs on a single row as you cannot even scroll up and down at all to show the covered up row.

Quick comments also on my observations: resizing the browser often can resolve it, including making the browser smaller/narrower. Sometimes it needs to be made wider, yet the data in table columns does not appear to be filling the space allocated for the columns.

Because the problem is not always easy to reproduce, fixes are hard to determine, but I’ve not see the issue since setting Table’s protected field alwaysRecalculateColumnWidths = true; So I don’t know if whatever that’s fixing is also fixing the issue, or whether it’s just a coincidence now. I’ll keep an eye out on it!

Did you manage to find a solution for your issue I have tried your suggestion (alwaysRecalculateColumnWidths) without success.
It seems to me that the last column is always too large compared to the table width forcing the scrollbar to appear… but I’m not sure …


Well, not entirely. It seems to happen less with alwaysRecalculateColumnWidths, but we still see it from time to time. It’s not clear why – and sometimes it refuses to render correctly even when we max the browser window.

When you see it next (or us), we probably should get into the HTML/DOM debugger in the browser and see/report what sort of settings it’s using as it must be some value Vaadin is not calculating correctly.

Actually I just checked and using alwaysRecalculateColumnWidths made it even worst, I’ve also noticed it happens most of the time when refreshing the page the first time I get to the page it can be OK (not always) but as soon as I refresh the page it breaks.
What information do you think we should extract from the DOM debugger as I can reproduce it almost everytime?

I’m not positive, but perhaps a Vaadin person could help answer this.

I’m guessing you are looking for CSS attributes like line-height, overflow, fixed sizes etc. on the row list or the like where the scrollbars appear.

You may also want to run the Vaadin debugger tool to do an analyze layout and see there are no issues (?debug added to the URL when productionMode=false

I tried the analyzer tool and when I click on the “analyze layouts button” I get no issues however the table gets displayed correctly :/.

We’ve seen that before, too. That’s why we thought the alwaysRecalculateColumnWidths might help since Vaadin seems to have all of the info, but it’s not properly being updated to the browser as ‘analyze’ fixes it. I’ve often wondered if this is related to other issues we have in which a message is queued up to the browser, but the browser has no request so it’s not received until later. We had hoped PUSH would solve this, but we’ve had nothing but problems with PUSH working over the Internet. We have seen that when PUSH is enabled (and running on our test PC), we get better UI looks because these “orphaned” updates to the UI make it through. The same occurs for popup layouts and popup buttons that sometimes do not “close themselves” until some other UI request occurs (except when PUSH is working on a local PC and it updates itself correctly).

I see what you mean I think also it might be some JS related problem since when I refresh the page for an instant the table is displayed OK before I get the annoying scrollbars…
I haven’t tried PUSH in our application but since you say it causes problems I won’t try it either…

Have you found it worse in some browsers than others? The most up-to-date Chrome on Windows 7 has been giving us grief recently, while Firefox renders okay now. I’ll see if we can do a bit more digging today to compare the two browsers and see if any settings seem off.

No on my side is the same result in the 3 major browsers, but the behavior is erratic so sometimes it works on some browser and not on another but what is constant is that it breaks when refreshing the page.

Yeah, I’ve seen that too, that a browser seems to work, then doesn’t, then does again…

I just noted in Chrome where it doesn’t work for me now, it shows "inherited fom div.v-scrollable.v-table-body-wrapper.v-table-body

Style Attribute {zoom: 1;
position: relative;
width: 946px;
height: 19px;}

If I “uncheck” height so it’s suppressed, then scrollbar is still present, but it doesn’t cover the row, which is the real key for me. Sometimes I noted that height is set to 20px.

And when I look at the element that was “inherited” from, it shows:

Edit and review

So I’m not sure why, but it seems when height is not used, it renders correctly on Chrome.

In the latest Firefox where I don’t see the issue, the height is set to 21px for the v-table-body-wrapper. I tried setting Chrome to 21px, but that made no difference (I had to uncheck to suppress it entirely).

Edit and review

Hi again,
Thanks for the input actually you are right it works on Firefox however you can see on the far right of the : v-table-body-wrapper A small difference between the row content ant the table wrapper ( I changed the background-color to red in the screenshot)… it is weird


After a few tests I can confirm that when you remove the height parameter the scrollbars dissapear on my side as well

Ok so finally after checking your different suggestions I managed to hack it to make it work with the following CSS rules:

height: auto !important;
border-collapse: collapse;

[/code]This makes it work for me on all the browsers; although Firefox and IE still show the margin on the far right; I can get rid of the margin by changing the following rule with the DOM inspector

.v-table-table{width: 100%} But this only works through the inspector and not if I put it in the SCSS file.

I’m not sure of the side-effects of these CSS Hack rules but maybe we should create a bug so the Vaadin team can solve it…

That looks like the space that would be used if there were a vertical scrollbar. Hmmm…

That’s what I thought too but I’m not sure (since the scrollbars are handled by the browser) it might be that the last column width is incorrect…

What theme are you using? We are using a customized Reindeer as our base and found that this was all we needed to make it work on Chrome. It seems like the latest IE, FF and Opera otherwise showed no issues.

.v-webkit .v-table-body-wrapper { height: auto !important; } The border-collapse seemed to cause horizontal scrollbar to appear and I couldn’t really tell what width was doing (did you try the !important since you said it was taking effect from your SCSS?).

Our styles.scss is:

@import "openesf.scss";
@include openesf;

and our openesf.scss starts with:

@import "../reindeer/reindeer.scss"; @mixin openesf { @include reindeer; ...then our stuff including... .v-webkit .v-table-body-wrapper { height: auto !important; } ...more of our stuff.... } /* end of @mixin openesf theme */ If you want to open a ticket, it may help to have them look into this and fix it. I don’t think our .v-webkit limit is critical since it seems to work fine without it, but as a rendering issue, we only find it’s a problem on Chrome (unsure about Safari since I don’t have a Mac).

I’m using Valo as a base theme.
The border collapse honestly I cannot remember after playing a while with different options it might be unnnecessary…
If I understand correctly on your side the “hack”

.v-table-body-wrapper{ height: auto !important; } makes it work properly on all browsers without the margin on the right side ?

In general, I’d say yes, no unexpected margins. However, I do see on “some rows” in “some tables” what appears to be an “unused column” that I suspect is what you also see. The table row highlighting doesn’t quite make it to the end, about the width of a vertical scrollbar, but no scrollbar is needed.

Even the table header rows seems to show this extra space (but only rarely to add to the debugging confusion). Sometimes the space appears briefly, and then is fixed, so perhaps it’s again some sort of timing issue with updates between Vaadin and the browser. I did note that if I expanded the final field’s column header to the full width of the table, horizontal scrollbars appear, but I can make it like 1-2pxs with careful dragging so the scrollbars disappear and that “extra space” is really small. But I can select another row from a control list that populates the other table and then that extra space is not present. Go figure!

At any rate, the height: auto fix is key for me on Chrome to avoid having a row covered up by the unneeded horizontal scrollbar, and the other extra space oddity is just a quirk without affecting usability so we’ll just live with it for now.