do not calculate size with hidden elements when resizing

[zaggino]

just a small fix when there's a hidden element (like invisible spinner toggled on demand) which causes $resizableElement to be smaller than it can be (and leaves weird space there)

Before:

After:

cc @peterflynn @RaymondLim

[peterflynn]

@zaggino I think even for something small like this we'd prefer you wait to give someone a chance to review before merging. Especially since we're nearing the end of a sprint. (We usually only "self-merge" zero-risk changes like README.md edits).

[zaggino]

Ok, sorry - won't do it again. Should I revert?

[peterflynn]

I think @RaymondLim or I should review it post-facto, but I don't think think we should worry about reverting unless we find some sort of problem...

[peterflynn]

@zaggino Sorry, just got a chance to look at this. I'm confused by what kind of 'hidden' elements require this -- lots of Brackets bottom panels are hidden using display: none (via jQuery .hide()), and they don't mess up the measurements at all. Is this change for visibility: hidden instead, or something? (In which case this would be a little weird since visibility: hidden is explicitly supposed to still take up space in the layout -- it's more like opacity: 0).

[redmunds]

I wonder if this may fix the problem with the sidebar that's been driving us nuts?

[zaggino]

Actual element here is <div class="spinner large"></div> and by looking at the Brackets classes it really uses visibility: hidden; so I'll be fine if this is reverted and I'll override this class in my styles. It didn't occur to me that this would be this case...

[peterflynn]

@zaggino Yeah, I think it might make sense to back this out since normally visibility: hidden is explicitly supposed to behave the opposite way. No rush though, just avoids confusion.

@redmunds It seems unlikely to affect #3376 since we don't normally have visibility: hidden DOM nodes in the editor area, and the bug still repros even after this PR landed.

[redmunds]

@peterflynn FYI, The problem with #3376 seems to be in the sidebar or project tree, not the editor (even though it's triggered from editor).

[peterflynn]

@redmunds Ok, in that case this seems even less likely to have any impact on that bug, since this code very specifically only applies to the #editor-holder DOM tree.