Closed Bug 13213 Opened 25 years ago Closed 23 years ago

[EVENTTARG] events don't reach elements to top or left of view (when nesting Relative CSS positioning inside Absolute CSS positioning, links inside translated part don't work anymore)

Categories

(Core :: Web Painting, defect, P3)

Product:
Core
Component:
Web Painting
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.9.9

People

(Reporter: dan6992, Assigned: roc)

References

(
URL
)

Details

(Keywords: helpwanted, relnote, Whiteboard: [Hixie-P2] [rtm-][nsbeta3-] relnote-devel)

Attachments

(2 files, 1 obsolete file)

Better testcase (incl. translucency, fixed positioning) (works!)
3.35 KB, text/html
Details
THE FIX
53.47 KB, patch
kmcclusk
: review+
waterson
: superreview+
Details | Diff | Splinter Review 
When a child element is placed outside of it's parent element's bounding
rectangle it does not register with event.target. Elements placed inside of the
parent elements bounding rectangle work fine.
I think the events are going to the wrong element to begin with - the clicks on
the out-of-border children seem to be going to the BODY node rather than the
positioned element.  This is yet another case of events going to the wrong
target.
I can see "Child clicked" in console window on clicking the child element.
May be it got fixed.
Let reported verify it.
In 1999-09-29-08-M11 Linux apprunner, it doesn't seem fixed.  If I click one of
the pink boxes outside the blue box, I see:

[object HTMLHtmlElement]

If I click one of the pink boxes inside the blue box, I see:

[object HTMLElement]
child clicked

These messages should be the same.

There are a whole bunch of bugs (at least 5 or so) about events going to the
wrong element.  Some of them (e.g., bug 1413) have been around for a long time.
I'm not even sure whether that's an event handling issue or whether the event
system is just getting incorrect information from layout.  (The bug on AREA
elements could also be related...)
Status: NEW → ASSIGNED
Target Milestone: M13
Moving targetting issues to M13
Summary: event.target does not work for child element positioned outside parent elements bounding rectangle → [EVENTTARG]event.target does not work for child element positioned outside parent elements bounding rectangle
Summary: [EVENTTARG]event.target does not work for child element positioned outside parent elements bounding rectangle → [EVENTTARG] event.target does not work for child element positioned outside parent elements bounding rectangle
Target Milestone: M13 → M16
Moving M16.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Fixed.  There is still a small bug in that the div hangs out of its border
slightly but clicking on the squares works fine.
Don't know whether the regressed or was never fully fixed.  But it doesn't work.  
The upper left square doesn't work right.  I suspect it may be a dupe of the 
negative margines bug but reopening anyway for further investigation.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This problem has never been fixed!!! I filed this bug in responce to the work 
I'm doing on the image map editor for ender. I am usine the exact same kind of 
code for teh resize handles on the shapes. When I have a rectangle which has 8 
handles (1 top left corner, 1 top center, 1 top right, 1 right center, 1 bottom 
right, 1 bottom center, 1 bottom left, 1 left center). The only ones that work 
properly are bottom center, bottom right, and right center, the other 5 do 
not. It seems to me that if a child object hanges either off the left or top 
edge of an element event.target is not registered properly. I will change the 
test case to reflect the exact situation I'm dealing with.
Another thing I noticed is that if a child element hangs partialy in and 
partialy out of the left or top of the parent, the portion inside the parent 
registers but the portion outside does not. I have also modified the test to 
reflect this.
I think the problem (remaining) here (after the changes I have in my tree are
in) is a bug in the view system.  Dump views on the above test case shows that
the views for the larger blocks (absolutely positioned elements get their own
views) have their bounds expanded to hold the child views to the right and
bottom, but not to the top and left.  The changes I have in my tree will thus
fix this on the right and bottom, but not the top and left.
*** Bug 22527 has been marked as a duplicate of this bug. ***
troy, beard - What should the views bounds be in this case?  Should views
completely contain their children, or should their origin coincide with the
frame for which they were created?  (Right now we seem to do the former on the
right and bottom, and the latter on the top and left.  See my previous comment.)
No views don't completely contain their children. The child views are allowed to 
stick outside their parent view. Then depending on whether the parent view is 
clipping children and the clip rect they may or may not be visible
This bug is preventing me from finishing my work on the image map editor! Please 
up it's priority so it will be fixed ASAP!
Blocks: 19430
Is it possible that this bug and Bug 13215 are related? Should they be marked as 
dependant on one another?
Hmm.  When I load this currently on Windows all of the non-responsive areas 
(anything to the left or top or the containing div) are initially not painted or 
possible painted over.  Since the event handling is done in reverse paint order 
it seems likely to be tied in.
Status: REOPENED → ASSIGNED
If there are painting problems then maybe bug 13215 is back.

The problem with this bug is the way the view is sized.  We need to decide 
whether the view code should change or the event handling code should change.  
The view code is internally inconistent too (it expands to hold children on the 
bottom and right).  See my 03-19 comment.
M16 has been out for a while now, these bugs target milestones need to be 
updated.
Updating Milestone to M18.
Target Milestone: M16 → M18
kmcclusk - I'd like to discuss the view issues involved on this bug with you
sometime.  This bug isn't that hard to fix, but we need to decide what the right
thing to do is.
Retitling and nominating for nsbeta3.  We should really fix this.
Keywords: nsbeta3
Summary: [EVENTTARG] event.target does not work for child element positioned outside parent elements bounding rectangle → [EVENTTARG] events don't reach elements to top or left of view
Taking this bug to keep it on my radar, and since joki is on sabbatical.
Assignee: joki → dbaron
Status: ASSIGNED → NEW
correctness of event routing among elements (child elements).
Keywords: correctness
Mass update:  changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
My attempt to fix this by commenting out the PointIsInside check in
nsView::HandleEvent caused major problems with comboboxes (e.g., at the top of
this page).  They started getting events that they shouldn't have...
Giving back to joki since I was too lazy to fix it while he was away.
Assignee: dbaron → joki
Status: ASSIGNED → NEW
Marking nsbeta3-.  Possible workaround would be to restructure the page.
Keywords: relnote
Whiteboard: [nsbeta3-]
PDT:  Renominating for nsbeta3+

Hmmnn...this sounds a little too serious to just ask the users to restructure 
their web pages (sorry Nisheeth).

Clearing nsbeta3 resolution.
Whiteboard: [nsbeta3-] → [nsbeta3]
I just tried using GetExtents instead of GetBounds, and it caused weird results
too...
We are really overloaded and this just doesn't make the cut.  Sorry!  Help 
wanted and appreciated!
Keywords: helpwanted
Whiteboard: [nsbeta3-]
This is really evil. The assumption that the coordinate system for a frame is 
the same as the coordinate system for its view is deeply entrenched.
I have a fix. It's a bit tricky but not as bad as I thought. The testcase works 
fine, trickier variations (e.g. widgets in the child views) seem to work fine 
too.

The general idea is to extend nsView so that its bounds can extend above and to 
the left of its frame's origin (I call the delta the "frame offset"). The 
top-left corner of the bounds is not revealed to client code using 
Get/SetPosition; it is only revealed by a call to GetBounds(). I modified almost 
all of layout to use GetPosition()/GetDimensions() instead of GetBounds(), that 
job should actually be finished to get this completely right. nsViewManager is 
modified to be aware of the frame offset and use GetBounds where necessary. The 
tricky thing is that the origin of the view's coordinate system remains the 
origin of the view's frame, which is no longer the same as the top left corner 
of the view's bounds. Even so, remarkably few changes were required.

If you think this might be checkin-able, I can try to backport the fix to 
nsViewManager2.
This is definitely a view bug --- reassigning.

I'm going to attach a patch. This patch changes the view interfaces slightly; in 
particular it changes the meaning of nsIView::SetBounds and nsIView::GetBounds, 
because their currently intended meaning is quite unclear in the presence of 
child elements extending above or to the left of the view. The patch also adds a 
new method to nsIViewManager so that layout can tell the view manager about 
views that have sticking-out children. Naturally, the patch also makes all 
necessary updates to use these new interfaces correctly. The patch does NOT, 
however, fix this bug; it just makes it possible to fix the bug by changing only 
the view manager. In fact, the patch should not change observed behavior at all.

The case for checking this in is simple: then I can produce another SMALL patch 
which adds nsViewManager to the build and provides a pref to switch view 
managers, so people can test this out easily.
Assignee: joki → kmcclusk
Component: Event Handling → Views
Robert: Good work on tracking down the core problem here.

I would prefer not to change the meaning of SetBounds and GetBounds. If we 
need to track the bounds of the view and all of its contents lets create a new 
bounds for that purpose.

The original design was that the views should not enclose their children. By 
modifying the mBounds so views enclose their children we are changing this core 
design. I believe with your change, instead of having the frames modify their 
views so they are always large enough to enclose their children, the views are 
doing it automatically.

I think we could fix this bug without modifying the meaning of mBounds by 
checking for views that are extend outside their parent view and make sure they 
are traversed inside nsView :: HandleEvent. 

If it is too inefficient to compute whether the view is outside the parent view 
each time during HandleEvent we could cache an mEventBounds for the view. (Which 
would be essentially the same thing your doing with mBounds in your patch.)

But at any rate, I think it is desirable to keep the mBounds distinct from the 
EventBounds. 

The layout team and others will be impacted by this change so I'm CC'ing a bunch 
of layout people
buster@netscape.com, attinasi@netscape.com, waterson@netscape.com,
karnaze@netscape.com
The meaning of the view bounds was changed quite some time ago, and not by me, 
so that the view encloses all the child frames that extend beyond the main frame 
in the positive x and y directions. This code has been true in the trunk for 
many months. I am just trying to make things consistent so that it encloses 
children in the negative x and y directions as well.

Before and after my change, the frames are responsible for sizing their views to 
contain all their frame children. This happens in 
nsContainerFrame::SyncFrameViewAfterReflow.

This does not just affect events. It also affects painting. It also affects the 
sizing and positioning of the view's widget, if it has one.

We could have a design where a view has two bounds: one set of bounds that is 
identical to its frame's bounds (in the coordinate system of the parent view, of 
course), and one set of bounds that encloses all children. I think we would find 
that the first set of bounds is not useful, except to get the frame's origin in 
the coordinates of the parent view. Such a design represents a deviation from 
existing assumptions, just as my design does.
What I'm meant by "the views should not enclose their children" was that the 
views shouldn't modify their bounds to enclose their child views. But it is 
perfectly acceptable for the frames to size and position the views to enclose 
all of the child frames. If they don't the frames will not be visible of course. 
If the frame's want to make sure they enclose the views with negative offsets 
that fine, but the view system should not expand their sizes automatically to 
make this happen.  I may be mistaken, but I had the impression that was what 
your patch was doing (i.e expanding the parent view to enclose it's child views 
with negative offsets.) 


No, each view is sized and positioned entirely by its frame, both before and 
after this patch.
I see this on Macintosh.
OS: Windows 95 → All
Hardware: PC → All
Adding rtm in hopes that someone can fix this! This is a big problem and will 
seriously stunt Netscape/Mozilla DHTML capability. I also believe it is directly 
related to Bug 13215. Please if you can do anything to fix this, do so ASAP! If 
a patch is in the works, or you have some other status on this bug please post 
it here.

Dan
Keywords: rtm
I have a patch in my tree which fixes this, but apparently Kevin's not sure it's 
the right fix, and is too busy to discuss it. So, we wait.
Kevin can you PLEASE look at Robert's patch??? If this doesn't get fixed soon my 
entire project could get dumped from the NS branch.

Dan
Dan, I'm afraid I have to tell you that the chances this will be fixed in the 
NS6 branch are approximately zero. The changes required are not very numerous or 
particularly hard, but they are quite fundamental, and will almost certainly be 
rejected by the PDT. The best we can hope for is to get this fixed on the trunk.
So Robert, by "fundamental" are you saying that the changes would be too 
high-risk to attempt on the branch at this point?
My patch changes the semantics of some of the frequently-used nsIView methods, 
but in a way that does *not* change behavior in the common case where a view's 
frame has no child frames sticking out of it above or to the left. So I think 
it's low risk, but I suspect PDT will disagree. And of course there's the fact 
that last we heard, Kevin either didn't understand the patch or didn't think it 
was the right fix.

If I'm wrong and PDT actually does want the fix for this, then I'd have to 
backport the view manager fixes from the new view manager to nsViewManager2. I'm 
not that interested in writing patches that will most likely be rejected by PDT 
and then immediately obsoleted when the new view manager lands. So I'd like to 
see PDT interest --- ideally, the view interface change patch checked in --- 
before I do that work.
Unfortunetly, this change is too large and too many people would have to OK it
to get in for rtm.  Marking rtm-.  We need to discuss this immediately after RTM.

Dan: perhaps we could try to come up with a work around which solves your
problem. Please contact me through email.
Whiteboard: [nsbeta3-] → [rtm-][nsbeta3-]
I did come up with a workaround for my project (I moved the children inside the 
parent), but I have to say I am still very disappointed about this! I filed this 
bug over a year ago and it was ignored until the last minute when it was too 
late to fix! This is going to be a huge blow to Netscape's DHTML ability and I 
believe it's going to draw a lot of negative reviews from the DHTML community. I 
only wish I would have pushed this one harder earlier on, then maybe someone 
would have realized how big of a problem it was and fixed it when they still 
had a chance. :(

All I can hope for now is that we can get this checked in to the trunk so that 
it will be fixed in the next point release.

Dan
Whiteboard: [rtm-][nsbeta3-] → [rtm-][nsbeta3-] relnote-devel
Robert: I have just gotten around to taking a another look at this patch. Sorry
for the long delay. The patch appears to allow the origin for the view's bounds
to be set. Rather than having the origin always being the upper left hand
corner, the origin for the bounds is set using the frame offset. Is this a
correct interpretation?

If so, could we change the terminalogy from frameOffset to boundOrigin or
viewOrigin. In general the view system is independent from frame system. Frames
know about view's but view's don't know about frames, so it would good to use
more general terminology within the view system to express the bounds offset.

What do you think?

Setting the view's origin should also be useful for implementing the css outline
property.
CSS "outline" is just another example of where a frame's content overflows its 
bounds. I think that layout already computes the overflowing rectangle correctly 
taking "outline" into account; once we've fixed this bug here, we should be 90% 
of the way to correct "outline" support.

I agree that the terminology is confusing and we need to fix that. Your 
point about not mentioning frames is a good one!

Each view has two important properties:
-- a rectangle which encloses the content of the view and all its subviews
-- a point which establishes the origin of the view's coordinate system
Currently the first property is called the "bounds" and is given in (x,y,w,h) 
coordinates relative to the parent view. The second property is forced to be the  
top left corner of the bounds.

I propose we call the first property the "view bounds rectangle" and the second 
property the "view origin". In the interface, we can specify both as being 
relative to the origin of the parent view. Normally the view origin will be 
equal to the top left corner of the view bounds rectangle, but obviously that 
won't always be the case.

Do you think that's too confusing?
"-- a rectangle which encloses the content of the view and all its subviews".

I would describe the bounds as the rectangular area which the view system
manages for painting and event handling. It shouldn't be described as enclosing
it's subviews. If the frame wants to expand the size of the view and reset the
view's origin to make this happen that's fine, but the view system doesn't
enforce this or require it.





I propose we call the first property the "view bounds rectangle" and the second
property the "view origin".

The view origin is a little "odd" in that we really are specifying the bounds
origin. If something were labelled "view origin",  I would expect a child views
position to be relative to the parent view's transformed origin (Comming from a
2-D graphics/tranformation mind set), but the child view's position is relative
to only it's parent view's position. The parent view's origin has no impact on
the child view's position at all.

Maybe we should just forget about calling it the origin altogether (to avoid
confusion) and call it bounds offset?



> I would describe the bounds as the rectangular area which the view system
> manages for painting and event handling. It shouldn't be described as
> enclosing it's subviews. If the frame wants to expand the size of the view and
> reset the view's origin to make this happen that's fine, but the view system
> doesn't enforce this or require it.

No --- nsViewManager and nsViewManager2 both require it. For example, if a 
view's bounds extends beyond the bounds of its parent view, then the child view 
doesn't receive mouse events properly. This is why this bug was reported in the 
first place!

Requiring that a view's bounds enclose the bounds of its child views is a good 
thing. Without this invariant, every repaint or mouse event would require 
traversal of the entire view tree.

> The view origin is a little "odd" in that we really are specifying the bounds
> origin. If something were labelled "view origin",  I would expect a child
> views position to be relative to the parent view's transformed origin (Comming
> from a 2-D graphics/tranformation mind set), but the child view's position is
> relative to only it's parent view's position. The parent view's origin has no
> impact on the child view's position at all.

I'm confused and maybe you are too. What do you mean by "position"?

The "view origin" I'm talking about is not the same as the "frame offset" used 
in the patch. I'm suggesting defining the "view origin" to be the point which is 
the (0,0) of the coordinate system defined by the view, and specifying it in 
coordinates relative to the parent view's "view origin". So indeed the parent 
view's origin does determine where the child view's origin is.

Perhaps an example would help. In the example of the testcase, the view 
tree would look something like this:

Root view: bounds=(0,0,1024,768), origin=(0,0)
    Child view: bounds=(430,30,240,240), origin=(450,50)
        Child view: bounds=(-20,-20,20,20), origin=(-20,-20)
        Child view: bounds=(-20,200,20,20), origin=(-20,200)
        Child view: bounds=(200,200,20,20), origin=(200,200)
        Child view: bounds=(200,-20,20,20), origin=(200,-20)
        ...
"No --- nsViewManager and nsViewManager2 both require it. For example, if a
view's bounds extends beyond the bounds of its parent view, then the child view
doesn't receive mouse events properly. This is why this bug was reported in the
first place!
"

How do we handle the case where the child view's are clipped by their parent view?

see troy's comment:

"No views don't completely contain their children. The child views are allowed
to stick outside their parent view. Then depending on whether the parent view is
clipping children and the clip rect they may or may not be visible."

Would we expand the parent view's size to contain it's children only if
overflow:hidden has not been specified?

I agree that the view system can not handle events and repainting of views which
extend outside the parent view's boundaries without adding a bunch of code, but
I was assumming we would leave it up to the frame to correctly size the view by
looking at the overflow property.

"I'm suggesting defining the "view origin" to be the point which is
the (0,0) of the coordinate system defined by the view"

Ok. I understand. I was thinking about it from the perspective of how do we set
the view's origin relative to it's coordinate space (bounding box). With your
definition setting the view origin and the current method SetPosition are
equivalent. We still need a method for setting the bounding boxes upper left
hand corner relative to the origin. I was thinking we would just call it
SetBoundingBoxOffset.





> see troy's comment:

Good point. OK, so the invariant is this:
IF a view is not clipping its child views, then its bounds must contain the 
bounds of its child views.

> I was assumming we would leave it up to the frame to correctly size the view
> by looking at the overflow property.

Yes! The invariant is maintained by the frame code, not the view system, and we 
should keep it this way. We may wish to add assertions to the view API to check 
that the frame code is doing the right thing.

> With your definition setting the view origin and the current method
> SetPosition are equivalent. We still need a method for setting the bounding
> boxes upper left hand corner relative to the origin. I was thinking we would
> just call it SetBoundingBoxOffset.

Actually, SetBounds (plus a little arithmetic) can be used to do this. 
SetFrameOffset is not needed. I'll remove it. Assuming I do this, add comments 
summarising this discussion, and remove all references to frames, are we 
converging on something you're happy with?

I think eventually we should take all the "update" methods out of nsIView and 
force the updates to go through nsIViewManager --- almost all modifications to 
the view system already go through nsIViewManager anyway. It would be neat to 
make nsIView a small read-only interface. The view system itself could use a 
private interface to the views to do updates. (Ultimately we could get rid of 
the nsIViewManager* pointer from nsView and pass it as a parameter everywhere 
it's needed.)
"Assuming I do this, add comments summarising this discussion, and remove all
references to frames, are we converging on something you're happy with?"

Yes, I think were there.

From the view modules perspective we have simply removed the limitation that the
origin of the view is also the upper left hand corner of it's bounding box.
We'll also have to post a message to the layout news group to make sure frame
authors are aware of this change.

Thanks for your patience in getting this hashed out. :-)


"I think eventually we should take all the "update" methods out of nsIView and
force the updates to go through nsIViewManager"

I agree.
Status: NEW → ASSIGNED
*** Bug 13215 has been marked as a duplicate of this bug. ***
*** Bug 60698 has been marked as a duplicate of this bug. ***
Milestone 0.8 has been released. We should either resolve this bug or update its
milestone.
Setting target to future.
Target Milestone: M18 → Future
Nom. nsbeta1.
Keywords: nsbeta1
QA Contact: ckritzer → petersen
Correct QA Contact->petersen
*** Bug 97000 has been marked as a duplicate of this bug. ***
roc, kmcclusk:  So, what's the status of this bug?  It really is a rather
serious bug, and it would be nice to see it fixed.
Summary: [EVENTTARG] events don't reach elements to top or left of view → [EVENTTARG] events don't reach elements to top or left of view (when nesting Relative CSS positioning inside Absolute CSS positioning, links inside translated part don't work anymore)
Whiteboard: [rtm-][nsbeta3-] relnote-devel → [Hixie-P2] [Hixie-1.0] [rtm-][nsbeta3-] relnote-devel
Blocks: 104166
*** Bug 91939 has been marked as a duplicate of this bug. ***
*** Bug 116516 has been marked as a duplicate of this bug. ***
*** Bug 65816 has been marked as a duplicate of this bug. ***
I'm working on the patch for this. It doesn't quite work yet, but it's pretty
close. It's going to be a little bit risky because there are a lot of places
where we assume view (top, left) == view's frame (top, left) and view's frame
(top, left) == view's widget (top, left), and many of those assumptions must be
broken.
Attached patch THE FIX — — Splinter Review 
OK, here it is. It's not very tricky, but there are a lot of places that needed
to be changed.

I have checked all the testcase in dups of this bug and they all seem fine
(except for one or two which need general display-list-aware event handling,
which is another project).

Risk: I touched a lot of code, but most of the changes should have no effect in
the common case where frame (top, left) and view (top, left) are the same.

Performance: Should be miniscule but given the size of the patch, maybe we
should run some page load tests?
Attachment #14791 - Attachment is obsolete: true
Note that with this patch in hand, it becomes very easy for frames to reliably
paint outside their bounds if they need to; just set the combinedArea during
reflow to whatever you need. This should make stuff like CSS2 'outline' and
'text-shadow' much easier to deal with, maybe other stuff too.

One issue which came up while I was doing this: what should we do about
'overflow: scroll' containers which have content above and to the left of their
origin? Presumably we should be able to scroll to view all of it. Presumably the
initial scroll position should be at the container's frame origin. Definitely
this would be a lot more work. Currently we can only scroll right and down from
the frame origin.
jgrm: Could you apply Robert's patch (id=64964) and run your page-loader tests
on one platform when you get a chance? Thanks!
Target Milestone: Future → mozilla0.9.9
Given that this seems to fix bug 120934, do we want to try to push this for
mozilla0.9.8, or are we not confident in this fix yet?
Keywords: mozilla0.9.8
I'm not confident. In fact I think there is a bug in popup positioning with this
patch. I will try to extract the relevent parts for bug 120934.
I tested (win2k) the current trunk vs. the current trunk with attachment 64964 [details] [diff] [review] 
(backing out rev 3.222 to nsViewManager.cpp to avoid a conflict). I did not see 
a significant difference (greater than 1%) in the times for the page load test.
(Sorry for not getting to this earlier).
kmcclusk, waterson --- I'd like to get this reviewed and checked in ASAP. It's
risky so we should do it as early on in the milestone as possible.
Assignee: kmcclusk → roc+moz
Status: ASSIGNED → NEW
Except I want to track down one bug first. So don't rush, just a heads-up :-).
Status: NEW → ASSIGNED
OK. I thought there was a popup bug but I can't reproduce it. I might have been
looking at the wrong build. So, please review the attached patch. Thanks!
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 23 years ago
Resolution: --- → WORKSFORME
Comment on attachment 64964 [details] [diff] [review]
THE FIX

Hope it works. rs=waterson.
Attachment #64964 - Flags: superreview+
You sure it's not that it causes you to accidentally resolve bugs as WORKSFORME? :-)
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Good work Robert!

I don't see any problems with the patch. 

I think it could use a little more explanation of how the view coordinate system
works with this change.

Something along the lines of:

SetPosition in conjuction with SetDimension establish the local coordinate space
for a view. SetPosition establishes the view's origin (0,0) relative to it's
parent's origin. SetDimension establishes The view's horizontal and vertical
extent relative to the view's origin. For example: to determine the absolute
coordinate for a view's upper left hand corner (It's offset from the root view)
you would compute the sum of all of the view's ancestor's positions (mPosX,
mPosY) then add the result to the view's dimension offset (mDimBounds.x,
mDimBounds.y)


The following comment is a little confusing:

nsView.h
nsRect  mDimBounds; // relative to parent


Isn't the mDimBounds rectangle relative to the view's mPosX, mPosy and the
view's mPosX, mPosY is relative to it's parent's mPosX, mPosY.
Whiteboard: [Hixie-P2] [Hixie-1.0] [rtm-][nsbeta3-] relnote-devel → [Hixie-P2] [rtm-][nsbeta3-] relnote-devel
No, actually that comment is correct. mDimBounds is stored in coordinates
relative to the parent view. Thus in the normal case, mDimBounds.x == mPosX and
mDimBounds.y == mPosY. That is why nsView::GetDimensions subtracts out the mPosX
and mPosY and nsView::GetBounds doesn't.

dbaron: OK, testing out the bugzilla comboboxes before submitting a comment was
a bad idea :-).

Chris: thanks for the vote of confidence :-).

After checking this in I will post to .layout and mention the API change this
entails: namely, you have to use nsIView::GetPosition when you want to translate
coordinates from one view coordinate system to another, but you have to use
nsIView::GetBounds if you want to find out the area covered by a view.
Marking FIXED
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: