Forum: Rails Spinoffs (closed, excessive spam) getDimensions() fails for elements with ancestors with display: none

Prototype v1.6.0.2

If any of an element's ancestors are hidden, Element.getDimensions()
returns misleading values. In order to address this in my own project,
I made the following modification:

getDimensions: function(element) {
    element = $(element);
    var display = element.getStyle('display');
+    var hiddenAncestor =  element.ancestors().any(function(e)
{ return e.getStyle('display') == 'none'; });
-    if (display != 'none' && display != null) // Safari bug
+    if (display != 'none' && display != null && !hiddenAncestor) //
Safari bug
.
.
.

but I imagine there is a more efficient way of doing this. I wanted to
bring this to the community's attention, see if anyone agrees with me
that this check should be added, and find out if someone with more
skillz than I could provide a better solution.

Thanks!

Yep, that's an old bummer : )
http://dev.rubyonrails.org/ticket/11142

- kangax

Thanks, kangax!

Do you know... which is the "proper" place to look for things like
this (patches, enhancements, etc.)? On the Rails Trac, or the
Prototype Lighthouse? or somewhere else? or are these being merged?

Also, looking at that patch, I realize that I didn't take into account
that the element I'm getting the dimensions of may not have its own
dimensions set. Oops. :)

One more, then I'll be on my merry way... What could I do to help get
this enhancement implemented?

Thanks again,
Lance

1) You should check both Lighthouse and Trac., though Lighthouse is
where all the new tracking happens.

2) I don't remember what stopped us from applying this enhancement. I
personally find it useful, but there are performance implications as
always. The patch also goes in hand with modified #recursivelyCollect
method (see one of the messages in that thread). Modified
#getDimensions was actually faster with modified #recursivelyCollect
(since it avoids double enumeration by filtering through iterator in
one loop). Having said that, it might actually make sense to add this
in 1.6.1 version (1.6.0.3 release is "bug-fixes only")

- kangax

Excellent. I think I'll go ahead and apply those patches for this
particular project, for now.

Is there a way I can vote for this enhancement to be put in 1.6.1? :)

thanks again!
lance

That's a great thought.
Would anyone be interested in something like "next-feature"/"most-
wanted"/etc. poll?

- kangax

kangax wrote:

 > On Jun 20, 5:23 pm, Lance <lroggendo...@gmail.com> wrote:
 >> Is there a way I can vote for this enhancement to be put in 1.6.1?
 >>
> That's a great thought.
> Would anyone be interested in something like "next-feature"/"most-
> wanted"/etc. poll?
> 

+1 for voting system.
+1 for applying http://dev.rubyonrails.org/ticket/11142 into core ASAP
I do need it. At the moment I use patched prototype.js, but I would
like this feature work out-of-the box in next prototype releases.


BTW.: This ticket was modified 4 months ago. I think there are chances
that this and other patches could be forgotten, burried somewhere in
the Trac, while developers switch to Lighthouse.
Do Core Developers still check Trac for "old" tickets?

--
Regards,
SWilk

We do check Trac sometimes, although it's a good idea to transfer
important tickets to LH (since that where they get most attention)

- kangax