Initial size of panes/position of splitbar is not always correct about ui-layout

[jbro-io]

Updates should be coming in the next week that resolve your issues. Here is your example tweaked to work with the upcoming update:
http://plnkr.co/eaP2qzTlL5NU0WDxKl3h?p=preview

[mindjuice]

Cool! Great to hear the new version is coming.

I tried making the same changes to my actual app as you made to my plunker, but there is a problem where the section labeled "Right subcontent" in the updated plunker gets a width:0 applied by ui-layout in my actual app.

Even if I paste the exact same html from the plunker into my html body, it applies the zero width to "Right subcontent".

Just wondering if I missed something with the changes you made:

• Changed to your beta versions of ui-layout.css and ui-layout.js
• Added ui-layout-container to the inner divs of ui-layout
• Added some wrapper divs with ui-layout-container for places that didn't have them

Anything else?

I thought it might be due to some bootstrap thing, but I switched the plunker to 2.3.2, which is what I'm using and it has the same issue (and of course the chevrons don't appear).

BTW, will there be a directive attribute to enable/disable whether a click on the chevrons opens/closes a pane?

Thanks,

Ken

[jbro-io]

@mindjuice that's really odd, any chance you could post a plunkr or demo that replicates your issue so I can take a look and see what's happening?

Yes in a future release I plan to add the ability to enable/disable the chevrons, unfortunately not in this go round though.

[mindjuice]

Email sent with plunker yesterday.

[mindjuice]

I just noticed as well that in the plunker I sent the layout doesn't update pane sizes when the window is resized. Not sure if that is the same issue or a different one at the moment.

[jbro-io]

Good catch. I'm going to try and plug that hole up today @mindjuice

I also received your email. I'll check out the code when I get home tonight and see what I can come up with.

[mindjuice]

Hi Jonathan, any update on either of these items? Let me know if I can help with testing.

Thanks,

Ken

[jbro-io]

Started a new job this week so my time is a little sporadic... Hoping to have it done Fri/Sat... I'll shoot ya a message when I push to github so you can help test it out for me. Thanks for all the help thus far by the way, much appreciated.

[mindjuice]

Hi Jonathan, any progress this weekend? Apologies if I'm asking too often, but I want to wrap up a beta of my project in the next 2-3 days and this is a pretty major issue. I'd look at it myself, but I'm working 14 hours a day on this project already. My capacity for reading and understanding another new codebase is nearing its limit at the moment! :-(

[jbro-io]

Just posted a fix for the window resize bug.
Still working on your specific issue for the Tab 2 resize.

[mindjuice]

Applied that patch and resizing works for me too. Thanks!

[mindjuice]

Not sure if I should file a separate issue for this, but I noticed that when resizing the window (using your latest patch), if you have dragged any splitbars to resize panes, they all snap back to their original size.

[mindjuice]

I've done some investigation into this and found a workaround for now.

In ctrl.updateDisplay(), getBoundingClientRect() is returning a rect with zero for top, left, width and height.

Digging a little further, this is because getBoundingClientRect() merges the rectangles returned by getClientRects(), which in my case is returning an empty array (length zero).

I'm not sure yet why this is the case, but think it might have something to do with all the children being set to position:absolute. I have confirmed that the children have width and heights.

The docs for getClientRects() do indicate that there is a difference between inline children and block children. https://developer.mozilla.org/en-US/docs/Web/API/Element.getClientRects

Anyway, as a result of the all-zero rectangle, the widths of some of my containers is being set to negative values (which the browser catches and resets to zero).

As a workaround for the moment, I've changed the code in the uiLayoutContainer directive:

scope.$watch('container.size', function(newValue) {
   // HACK!!!  This avoids the initial case where width is set to a value less than zero
   if (newValue >= 0) {
      element.css(ctrl.sizeProperties.sizeProperty, newValue + 'px');
   }
});

Not sure if this will give you any help on tracking down the problem further. For the moment this fixes my issue though. If you haven't found the problem in a couple of weeks, I'll come back and take a look after I've finished the other features of my web app.

Thanks.

[jbro-io]

@mindjuice doesn't your latest PR address this as well?

[mindjuice]

Actually, it does! I hadn't thought about that, but after removing my HACK code from above, it still works.

There is one issue that I thought would be fixed when this was addressed, but apparently it is a separate issue.

The issue is that, although the panes appear in the correct positions initially now, one of the panes briefly expands to the full container size momentarily when you first drag the splitbar.

In my case, I have a set of two columns contained in a set of two rows, and the right column briefly covers over the left column and then as you move the mouse, it corrects itself. I'll try to see if I can reproduce this in a plunker tomorrow.

[mindjuice]

Sorry...I take it back. I didn't notice that my build script hadn't refreshed my code in the browser.

It doesn't work with my latest PR.

[SomeKittens]

Closing this, as the initial issue seems to have been fixed. Using #100 to track the window resizing issue. Thanks!