Closed Bug 34500 Opened 25 years ago Closed 24 years ago

Need ability to get frame x/y/width/height from DOM

Categories

(Core :: DOM: CSS Object Model, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: mikepinkerton, Assigned: jst)

Details

(Whiteboard: (py8ieh:reopen))

For drag and drop, we need to know where a particular frame is within a window so that we can build up a drag region corresponding to it. I was told once that this might be part of DOM level 2, but please change the component if that's incorrect. This info needs to be accessable from JavaScript so those implementing d&d in their component only need to write in JS (as is the case now).
Blocks: 34497
Yup, the DOM Level 2 does define this, I already have a bug on this so I'll mark this as a dup of that. *** This bug has been marked as a duplicate of 32169 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
No longer blocks: 34497
My bad, this is not a dup of bug #32169, reopening.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
And, as a matter of fact the DOM does *not* define this, IE 5 has support for the properties offsetLeft, offsetTop, offsetWidth, and offsetHeight and mozilla has some initial support for those, but that's only for HTML, I assume that support for similar functionality is needed for XUL too, right?
right. we need this for xul. joki told me it was going to be in the DOM2 spec a while back. he could have been mistaken or things may have changed.
Mike, Johnny--can we live without this for FCS? This means we would have no d&d between different frames, right?
no, it just means that drag feedback suffers greatly.
I'd like to point out that this is a general limitation on the flexiblity of chrome, not limited to this particular d&d problem. I've run into it myself.
Status: REOPENED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → FIXED
Hey, I've got great news, the bug this initally was marked a dup of is fixed, and as it turned out this really should have remained a dup of that bug. The fact is, as of a few days ago (5/16) you can use getComputedStyle() to get x, y, w and h for any elements in any document (or view (AKA window in our DOM), actually). To do that in JS you could write something like this: var e = getElementById('xxx'); var val = getComputedStyle(e, ''); x = val.getPropertyCSSValue('left'). getFloatValue(CSSPrimitiveValue.CSS_PX)); to get the absolute 'x' position in pixels (you can do correct unit conversions too if that's something you want to do) for the element 'e'. The current getComputedStyle() implemetation only implements the properties left, top, right, bottom, width, height and display, if you need support for more poperties please have a look at bug 39892, and if you find problems with the currently implemented properties, file a bug against me. Since the functionality requested in this bug does exest now, I'm marking it FIXED.
Component: DOM Level 2 → DOM Style
Taking QA Contact on all open or unverified DOM Style bugs...
QA Contact: vidur → ian
So, um, despite my best efforts I can't get getComputedStyle() to return anything other than '0' for 'left'. Should I open a new bug, or reopen this one? In case it's an error in my test case, you may look at it here: http://www.hixie.ch/tests/adhoc/dom/css/computed/002.xml
Whiteboard: (py8ieh:reopen)
jst? See my comments above.
Hixie, the problem is that you're executing your test code from inline script while the document is being loaded, and since we don't do any kind of incremental layout of xml documents there's frames for any of the elements whose position you're asking for, so you always get 0. Make your code execute from the onload handler and you'll get non 0 values.
Ok, I fixed the script and now four of the tests (out of 12) do indeed come out correct. VERIFIED.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.