Announcement

**Isomorphic** · 27 Sep 2011, 08:22

Yes, it's probably CSS or inline styling in content. What's happening is that the browser is reporting that the content is large enough that scrollbars will be required, then SmartGWT shrinks the content area to add scrollbars, then the browser reports that the content is no longer long enough to require scrollbars. Basically a browser bug.

Unlikely to be a difference between 2.4 and 2.5 so look for differences in the contained content instead, including differences in CSS styles applied.

**jmichelgarcia** · 28 Sep 2011, 00:09

Thank you for your help.

I will try to check for CSS being applied, and try to override those properties. (Since i can't change Liferay's CSS).

**jmichelgarcia** · 28 Sep 2011, 03:58

I managed to resolve the blinking issue simplifying the layouts managers.

But my ListGrid, still always show theirs scrollbars.

I've put in attachment, a screenshot of the ListGrid once the page loads. Then, when I click on the scrollbar and move it, the scrollbars disappears.

The problem still happens in FF 7.

Initially I though that the problem was with the ScrollBar gap, and even removing it, the visual bug persists.

I will take a deeper look into CSS now.

Is there any workaround for this ?

----------
PROBLEM PARTIALLY SOLVED

After a couple of hours searching I managed to solve the problem.

Initially, I had this :

- VLayout
\-- HLayout
\-- ListGrid
\-- HLayout

and having the problem stated before, I changed to :

- VLayout
\-- HLayout
\-- HLayout
\----\ ListGrid
\-- HLayout

Inserting the ListGrid into a surrounding VLayout solved the problem.

Attached Files

**jmichelgarcia** · 28 Sep 2011, 06:20

In fact, doing that solve the visual problem, but now my application is using 50% of the CPU, and resulting in a growing firefox used memory problem.

Once all my portlets are embedded into Liferay, it seems that some CSS from the Liferay theme are messing with the SmartGWT "perfect pixel" system.

Im having the same problem with : ListGrid and Trees.

This resulting in a gorgeous number of redraws and causing my app to freeze.

Any solution ? help ? clues ?

Im getting crazy.

Please advise me.

**Isomorphic** · 28 Sep 2011, 09:14

Again, its some kind of bad CSS from Liferay, probably a poor practice such as applying padding to all tables elements regardless of whether they are rendered by Liferay itself or a portlet. Isolate the problematic CSS (Firebug can help here), then you'll be able to compensate for it.

**jmichelgarcia** · 3 Oct 2011, 13:24

Hi Isomorphic,

So, after some digg, here's an example of the problem im facing.

In the classic Liferay theme, I have some css definitions like that :

input[text] { padding: 0px; }

which it's conflicting with Smart GWT rules like

.textItem { padding: 2px; }

I have many ex like thay cause my portlet not to be perfectly showing.
So, I cannot change the Liferay CSS (not managed by me). I was willing to add !important to all css SmartGWT rules, because is the only solution I see.

Do you thing is a good approach? Can I manage to do this automatically?

I do really appreciate your help on this, it's driving me crazy !

Cheers

**Isomorphic** · 3 Oct 2011, 13:29

That's what we suspected, and it's bad practice generally, but it's spectacularly bad practice for a portal, as it affects all HTML rendered by anything in the portal. If you haven't yet, we'd recommend looking to see if there is Liferay bug filed for this with a workaround. If not, yes, marking our rules !important would be a workaround.

**jmichelgarcia** · 4 Oct 2011, 05:37

So,

I've managed to add !important to all SmartGWT css rules using a Maven plugin.

Has if I have a choice, I can't give up on trying lol.

So, still some glitches.

Here's some screens in attachments. In red, you can see Liferay's CSS still appearing lol.

Here's the bug/improvment report : http://issues.liferay.com/browse/LPS-21775

PLEASE ADVISE

Attached Files

**Isomorphic** · 4 Oct 2011, 06:41

Liferay includes CSS that sets border-collapse and border-spacing for all <table> elements? That's... what's a word stronger than spectacular?

The only way around this would be to reverse this setting on all SGWT-generated <table> elements - you could do this with a CSS rule that you apply to your outermost SGWT widget that affects all <table> elements found within that element.

However, we noticed that what you've done is filed a new bug with Liferay for this problem - what we actually meant to suggest was to look for an *existing* bug against Liferay for this issue. Many, many different frameworks would show visual glitches when CSS is used to change the default behaviors of HTML elements, so this bug has probably been filed before, and there may be a workaround provided.

**jmichelgarcia** · 4 Oct 2011, 06:50

I will follow your advise concerning the CSS rule, and I will take a better look against already reported issues.

Im perhaps missunderstanding Liferay way of working here.

I'll digg !

Big thanks

**jmichelgarcia** · 4 Oct 2011, 07:01

Hey Isomorphic team,

Seems that not everyone has good CSS practises, here's a answer in Liferay's forum.

"No, from the browser perspective it gets a bunch of css to apply to the page and has no idea that there are separate portlets on the page.

I've had similar issues w/ creating Vaadin portlets. The Vaadin widget set has it's own theme but, when used within a portlet, sometimes does not render correctly because the Vaadin theme expects it is the only CSS styling the Vaadin widgets.

The solution is to undo the Liferay standard CSS stuff in your specific classes. For example, if your <ul> object is given a class "my-treeview", you'd have the extjs class stuff in there, but you'd probably also have things to disable the margin and padding stuff that LR normally applies.

I found that the web developer toolbar in Firefox is useful to identify all the CSS stuff applied to a given element so you can see the kinds of things you'll need to undo in your specific class"

by David H Nebinger

**Isomorphic** · 4 Oct 2011, 07:13

Not sure what you mean by "seems that not everyone has good CSS practises" - what this person on the forums is saying is that Liferay's poor CSS practices affect multiple frameworks (Vaadin, Ext, others) - exactly what we said. It's Liferay at fault in all of these cases.

And the suggested workaround is exactly what we've suggested to you - use extra CSS to explicitly reverse Liferay's damaging CSS settings. It's unfortunate that there is not yet an official fix from Liferay.

**jmichelgarcia** · 4 Oct 2011, 07:15

Originally posted by Isomorphic

Not sure what you mean by "seems that not everyone has good CSS practises" - what this person on the forums is saying is that Liferay's poor CSS practices affect multiple frameworks (Vaadin, Ext, others) - exactly what we said. It's Liferay at fault in all of these cases.

And the suggested workaround is exactly what we've suggested to you - use extra CSS to explicitly reverse Liferay's damaging CSS settings. It's unfortunate that there is not yet an official fix from Liferay.

What im saying, is that Liferay could also use a better CSS approach. Like you guys do.

Thanks for everything.

I still plan to do a huge Tutorial on this, as soon as I will finish it.

Cheers.

**Isomorphic** · 4 Oct 2011, 07:16

Ah good, glad we're clear. And we look forward to the tutorial!

Announcement

ListGrid scrollbars gone crazy

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment