[jclaxton]

Somehow we never had the skin properly applied, but older smartgwt.jar's were using it as the default. I fixed my gwt.xml to inherit Enterprise and that resolved the styling and misalignment issues. Thanks so much for your help!

[Isomorphic]

Hmm - the blue-header skin has been the default for a long time - it's called "Tahoe" and is also what you see on our showcase. I don't think anything's changed on our end that would cause you to be seeing a different skin in an otherwise unchanged application (when your previous build was a recent nightly from the 12.1d branch)

The previous default, and what appears to be in your earlier screenshots was called "Enterprise".

I'm guessing that you've inadvertently modified your .gwt.xml file to inherit different module(s) by default and/or modified the bootstrap HTML file to have a different <script src=...> tag for loading the skin.
We have an overview doc about skinning / loading skins here: https://www.smartclient.com/smartgwt.../Skinning.html
But in short you probably want to ensure that in your .gwt.xml file you're inheriting the "NoTheme" version of SmartGWT and then also including an inherit tag for the desired skin itself - something like <inherits name="com.smartclient.theme.enterprise.Enterprise"/> (Alternatively, if you're using explicit <script src=.." tags in your bootstrap to load resources, you'll want to inherit the EnterpriseResources only and have a script tag to load the "load_skin.js" file for the included skin.

Given that you were seeing Enterprise before, I suspect you've had this setup in the past so it should be easy to resolve.

In terms of why the heights of rows would be changing on rollover - this can happen if css borders for the "Over" styles applied to listgrid cells differ in thickness from css borders for the normal styles. We avoid this with our skins by default but it's likely some custom styling of yours is overriding this in a way that happens to break when applied on top of Tahoe but not for Enterprise. The fix typically is to ensure border thicknesses match up for all the states' css styles - even if this means applying borders that are of the same background color as the cell or transparent.

Let us know if you need further assistance with this

Regards
Isomorphic Software

[jclaxton]

I think that (almost) did it! I tested with the Nov. 8th nightly and both my test case and my actual app are no longer getting misaligned when I scroll. But the new jar seems to use a different default skin (the headers are blue instead of grey). And hovering over each cell changes it's height by a couple pixels, causing a small misalignment.

[Isomorphic]

Hi again!
Please try the next nightly 12.0p branch (Nov 3). Let us know if you continue to see the problem.

Thanks and Regards
Isomorphic Software

[jclaxton]

Right, my test case hasn't changed. A couple notes:

-It does jump around less. Occasionally I'll see it jump up a bit, but I'm no longer getting into loops where it keeps jumping.
-Clicking on a frozen column doesn't seem to be an important detail anymore. Clicking the unfrozen one and quickly scrolling to the bottom causes misalignment about 50% of the time.

Thanks for chasing this, I know these graphical/timing issues can be tough.

[Isomorphic]

Ok thanks for letting us know. We have made some changes in this area but this is proving surprisingly tricky to get fully resolved.
Can you just confirm the following points:
- you're still testing this using the code from the first post (with the "!important" directives removed from the CSS). If that's not correct, can you post whatever sample code you are testing with so we can be sure we're looking at the same thing
- you're using Chrome,
- ensuring the Window is sized large enough that the grid height is about 500px,
- clicking on the frozen columns
- scrolling up and down using the mouse wheel.

And the result you're seeing is that the frozen and unfrozen body cells become misaligned at some point, and the scrollbar thumb appears to jump around oddly

Is that all accurate? Any details we've got wrong / anything to add?

(As an aside - we do consider this a serious issue to resolve)
Thanks

[jclaxton]

Yes, I tested in Chrome and the behavior seems to be the same.

[Isomorphic]

Are you still seeing a problem with the latest build?

[jclaxton]

Has there been any progress on this issue?

[Isomorphic]

Thanks for letting us know. The fix we introduced was indeed IE-focused and would resolve a common misalignment case. We are still working (in the background) on another case where things could render incorrectly with certain scroll interactions, but we did not believe this could impact your particular usage.
Anyway - we're still on this and have noted your additional manifestation of the issue. We'll follow up when we have more information for you.

Regards
Isomorphic Software

[jclaxton]

Thanks for the response, sorry I'm just getting to testing now.

I'm still seeing the issue in the 9/24 nightly build. IE seems somewhat more stable, but I can still break it if I use the scroll wheel quickly. Chrome seems the same at the last build. Both seem to get better as you leave the page open, so a good way to see the error is to reload the page and use the scroll wheel to quickly go to the last row (that's how I got the attached screenshot) in IE.

I don't mean to be a nuisance over a minor issue, but the issue is worse in my actual implementation, which is considerable more complicated. I'm hoping that addressing the issues that I was able to isolate in the test case will fix the more nebulous issues in my app.

Version: SNAPSHOT_v12.1d_2018-09-24/LGPL Development Only (built 2018-09-24)

[Isomorphic]

We found we could reproduce this issue in Internet Explorer, and have made a change which should address this.
Please try the next nightly build, dated September 14, on the 12.0 or 12.1d branch

Regards
Isomorphic Software

[Isomorphic]

Thanks for the extra information - we're taking a look.

[jclaxton]

I was able to recreate the issue with that same test case, minus the "!important" keyword. It seems like you have to scroll in a particular way to see it, and even then, it doesn't happen every time. In the attached gif, I started recording in a misaligned state, clicked on a frozen cell, scrolled to the top, and then scrolled to the bottom. I used the scroll wheel the whole time. Also, about a third of the way through scrolling down, you can see the scroll bar jump to the top.

These details seem to be important for reproducing it:

• Having mouse focus or hovering over the frozen column
• Using the scroll bar
• Resizing your window so you have a lots of room to scroll (or just set the grid height to about 500px)

[jclaxton]

OK, thanks. The "!important" was just left over from an older test case; we don't need support for that at the framework level. My actual implementation doesn't use it, but I'm still seeing the issue. Let me see if I can get you a more representative test case.