Side navigation
#2528 closed bug (invalid)
Opened March 15, 2008 07:49PM UTC
Closed March 18, 2009 03:23AM UTC
Last modified March 14, 2012 05:12AM UTC
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: |
Description
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)
Change History (3)
Changed March 17, 2008 10:20AM UTC by comment:1
| resolution: | → invalid |
|---|---|
| status: | new → closed |
Changed September 10, 2008 07:51PM UTC by comment:2
| resolution: | invalid |
|---|---|
| status: | closed → reopened |
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 );
Changed March 18, 2009 03:23AM UTC by comment:3
| resolution: | → invalid |
|---|---|
| status: | reopened → closed |
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.
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.