Bug Tracker

Opened 9 years ago

Closed 8 years ago

Last modified 5 years ago

#2528 closed bug (invalid)

Getting position of hidden element generates error in Firefox

Reported by: opgobee Owned by: paul
Priority: minor Milestone: 1.2.4
Component: dimensions Version: 1.2.3
Keywords: dimensions and core Cc:
Blocked by: Blocking:


I'm a newbie, please correct me if I submit this in the wrong way or wrong place.

Problem: Calling .position() on an element that has display:"none" causes error "[Exception... "Could not convert JavaScript argument..." only on Firefox, not on IE7. Demo see: http://www.justarrangingbits.org/webtech/jQuery/demos/displayNoneParentOffset.htm (contains Firebug lite, so is directly testable in IE too)

I tracked it down, the origin seems twofold:

Dimensions plugin (line 108) calls the property .offsetParent of the hidden element. In FF this returns NULL, in IE the <body> element (FF also returns the <body> element if the element is not hidden).

Next, in the same Dimensions plugin (line 111) the retrieved value is wrapped in a jQuery object and returned. It appears $(null)== jQuery object containing <document>

After a series of intermediate steps the <document> ends up as 'elem' in jquery.js in line 876 : var getComputedStyle = document.defaultView.getComputedStyle( elem, null ); where it generates the error.

I wrote a colour-coded document that I'll try to attach that clarifies all intermediate steps.

Is it by design that $(null)== <document> ?

Finally, is there a resemblance of the behaviour that FF returns NULL as offsetParent on a hidden element with ticket 1779 stating that FF creates an error in a similar line of code with an animation in a hidden I-frame?

I didn't yet further track down in jquery.js why $(null)== <document>, also can't judge where along the line remediation of this combined issue preferably would be applied, but I hope this issue might be remedied. I bumped into this because I have an app. where a connected set of elements of which some can temporarily be hidden, have to be operated on, using position().

Thanks, Paul

Attachments (1)

JQuery hide position error.doc (31.0 KB) - added by opgobee 9 years ago.
Word-document clarifying the routing of the error

Download all attachments as: .zip

Change History (4)

Changed 9 years ago by opgobee

Word-document clarifying the routing of the error

comment:1 Changed 9 years ago by paul

Resolution: invalid
Status: newclosed

Hi, calling position() or offset() on a hidden element is not supported by the browsers, because the element logically doesn't take up any space in the page, and therefore doesn't have a position. Different is visibility set to hidden: The element then still takes up the space, but is simply not visible.

comment:2 Changed 9 years ago by Bosmon

Resolution: invalid
Status: closedreopened

Although it is "not supported", this error should not be provoked by the library. In trying to remove flickering issues with draggables in Opera, we must make sure that the avatar is set to hidden when created - in mouseStart, there is a call made to offset() which fails with this error within curCSS. Whilst this could be fixed within JQuery UI, it would seem to be better to make curCSS more robust so that this error could not be triggered from getComputedStyle.

For reference, in Jquery 1.2.6 the error is triggered on line 871

var computedStyle = defaultView.getComputedStyle( elem, null );

comment:3 Changed 8 years ago by brandon

Resolution: invalid
Status: reopenedclosed

In order to get the offset the element must be visible. Either the offset method must do some detection work to figure out if it is hidden, then show it, and finally hide it... or the developer can just call .show().offset() and then .hide(). The overhead associated with putting the logic inside offset/position isn't justifiable in an already expensive operation.

It is better to show the error than to hide it and give some odd result that is unexpected.

Note: See TracTickets for help on using tickets.