[CLOSED] do not calculate size with hidden elements when resizing

[core-ai-bot]

Issue by zaggino
Friday Apr 04, 2014 at 22:51 GMT
Originally opened as adobe/brackets#7417

---

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

---

zaggino included the following code: https://github.com/adobe/brackets/pull/7417/commits

[core-ai-bot]

Comment by peterflynn
Friday Apr 04, 2014 at 23:04 GMT

---

@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).

[core-ai-bot]

Comment by zaggino
Friday Apr 04, 2014 at 23:07 GMT

---

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

[core-ai-bot]

Comment by peterflynn
Friday Apr 04, 2014 at 23:16 GMT

---

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...

[core-ai-bot]

Comment by peterflynn
Tuesday Apr 15, 2014 at 23:43 GMT

---

@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).

[core-ai-bot]

Comment by redmunds
Wednesday Apr 16, 2014 at 00:05 GMT

---

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

[core-ai-bot]

Comment by zaggino
Wednesday Apr 16, 2014 at 00:09 GMT

---

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...

[core-ai-bot]

Comment by peterflynn
Wednesday Apr 16, 2014 at 04:10 GMT

---

@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.

[core-ai-bot]

Comment by redmunds
Wednesday Apr 16, 2014 at 14:41 GMT

---

@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).

[core-ai-bot]

Comment by peterflynn
Wednesday Apr 16, 2014 at 20:21 GMT

---

@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.