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)
Core
DOM: CSS Object Model
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).
Assignee | ||
Comment 1•25 years ago
|
||
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
Assignee | ||
Comment 2•25 years ago
|
||
My bad, this is not a dup of bug #32169, reopening.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Assignee | ||
Comment 3•25 years ago
|
||
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?
Reporter | ||
Comment 4•25 years ago
|
||
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.
Comment 5•24 years ago
|
||
Mike, Johnny--can we live without this for FCS? This means we would have no d&d
between different frames, right?
Reporter | ||
Comment 6•24 years ago
|
||
no, it just means that drag feedback suffers greatly.
Comment 7•24 years ago
|
||
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.
Assignee | ||
Updated•24 years ago
|
Status: REOPENED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 8•24 years ago
|
||
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.
Updated•24 years ago
|
Component: DOM Level 2 → DOM Style
Comment 9•24 years ago
|
||
Taking QA Contact on all open or unverified DOM Style bugs...
QA Contact: vidur → ian
Comment 10•23 years ago
|
||
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)
Comment 11•23 years ago
|
||
jst? See my comments above.
Assignee | ||
Comment 12•23 years ago
|
||
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.
Comment 13•23 years ago
|
||
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.
Description
•