[CLOSED] I'm having a slight problem with heights in panels with content layouts under certain Chrome screen sizes, but not all.

[michaeld]

The issue is with panel heights and I'm confident layouts are properly defined so I've disqualified flex and layout type. I'm pretty sure the issue is an extjs bug in Chrome only but it's not been possible to recreate in a simple sample. The best I can do is encourage you to take a look at www.scenecalendar.com (Upcoming Events tab) and attempt to resize the browser to a small width and refresh until it appears. It usually happens when the screen is smaller and instantly resolves on browser resize (most of the time). You can observe the issue in the leftmost panel in the Event Details. Event detail containers (class=CalItem) begin to overlap on top of each other. Hover the mouse over the panels should background highlight what the size should be.

If I was to take a stab at what I think is happening, I'd explain that I think the layout resize calculation and panel draw is happening before the final html rendering completes. But I cannot be sure. I haven't used overflow overrides in css so I'm suspecting it's related to something in extjs.

Mind giving your thoughts? I'm considering and final container update/refresh after the page has finished rendering.

[Daniil]

Hi @michaeld,

Could you, please, provide a screenshot? To be sure what we should try to reproduce.

[michaeld]

As you can see...
First image is first refresh.
Second image is after resizing the browser even a pixel or two.

[Baidaly]

Hello!

Strange, I couldn't reproduce. Does this issue happen only in Chrome? What are exact step to reproduce?

[michaeld]

Strange, I couldn't reproduce. Does this issue happen only in Chrome? What are exact step to reproduce?

Yes, only in Chrome. My version of chrome is Version 30.0.1599.101 m

The steps to reproduce... Shrink the width of the browser to a smaller size, refresh the page. If it works, shrink it more and refresh until issue appears. Certain sizes tend to make the issue more pronounce. The smaller the width, the more likely it appears. I can reproduce with small width pretty consistently every time.

I'm updating chrome now to see if newer versions behave.

[michaeld]

New version, same problem
Version 31.0.1650.48 m

[Daniil]

Seems I reproduced.

I am afraid it is how the raw HTML is laying out and not affected by Ext.NET/ExtJS layouts.

[michaeld]

Okay, if I go with that, any advise on how to overcome? I realize it's not your job to tech support style issues, but these are standard divs, img, spans, and and anchors with basic style information like padding, color, margins, and font.

Could it be that the linked css file is loading after the panel is rendered so size information isn't yet completely resolved by the time extjs gets to it? Should I embed the style information? Any advise to diagnose?

Also, if that's not it, can you suggest a way I can trigger a late event to refresh the panel layouts after the page has loaded only for chrome (server-side code)? Like an event this would reproduce the effect of a resize?

[Daniil]

Okay, if I go with that, any advise on how to overcome?

Maybe, the "overflow: hidden;" rule could help somewhere. I see the things are going to next lines when no width enough and, as far as I can understand, it breaks layout.

Could it be that the linked css file is loading after the panel is rendered so size information isn't yet completely resolved by the time extjs gets to it?

I don't think so. Though, not sure for 100%.

Also, if that's not it, can you suggest a way I can trigger a late event to refresh the panel layouts after the page has loaded only for chrome (server-side code)? Like an event this would reproduce the effect of a resize?

Maybe, call the DoLayout method after of some container. Though, not sure it will help.

I would also consider setting MinWidth for the problematic container.

[michaeld]

Thought I'd update you... This hack addresses the problem...

			<AfterRender Single="true" Delay="1" Handler="if(Ext.isChrome) #{ViewP}.doLayout();" />

The key is in the delay. If there's no delay or it's zero (0), the heights do not correct. This suggests to me my original assumption about timing might be the issue. The delay=1 forces the doLayout to wait till later after more of the page is rendered, then resolves the heights correctly because of it. I still really believe this is a client-side bug because a late doLayout is a hack to force that browser to wait longer before the heights can be properly resolved.