Closed Bug 79315 Opened 23 years ago Closed 21 years ago

[rel pos]Overflow of relatively positioned elements not painted/repainted

Categories

(Core :: Layout: Positioned, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla1.5beta

People

(Reporter: ronbu, Assigned: dbaron)

References

(Blocks 1 open bug, )

Details

(Keywords: testcase, Whiteboard: [patch])

Attachments

(7 files, 3 obsolete files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9) Gecko/20010505
BuildID:    2001050515

In the page at http://members.truepath.com/ron/banner.htm , only the bottom part
of five of the images are drawn.  This page has a menu that is positioned at the
top of the page, using CSS fixed positioning.

Reproducible: Always
Steps to Reproduce:
1.Go to http://members.truepath.com/ron/banner.htm
2.Scroll down to see those five images.


Actual Results:  Only the bottom part of the images are shown.

Expected Results:  The whole images should be shown.

This page has a special message that is displayed only to Gecko users with
Javascript turned on.  I have demonstrated that the Javascript message is not
the cause of the bug.
I'm seeing this on Windows 2000 Build 2001050720
-->imagelib (not image conversion)
Assignee: mjudge → pavlov
Component: Image Conversion Library → ImageLib
Changing status to [imglib], i see this on W2K build 2001050804
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [imglib]
Whiteboard: [imglib] → [imglib] DUPME
Pav sez: he has a dup should be fixed by 0.9.2
Keywords: qawanted
Target Milestone: --- → mozilla0.9.2
over to layout.  this looks like a its related to the css and absolute 
positioning.
Assignee: pavlov → karnaze
Component: ImageLib → Layout
QA Contact: tpreston → petersen
Target Milestone: mozilla0.9.2 → ---
current testcase no longer valid.
not a table specific bug, reassinging to core owner.
Assignee: karnaze → attinasi
Whiteboard: [imglib] DUPME → [imglib] DUPME [NEED TESTCASE]
the images are no longer referenced on the page, without a test case we can't 
reproduce. Marking as wfm, reporter if you can attach a testcase that can be 
used to reproduce the problem then please attach and reopen the bug
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Attached file Relatively positioned image links (obsolete) —
This attachment demonstrates that if a linked image is relatively positioned at
the anchor tag level, the top part of the image vanishes.  The entire image
displays in Opera 6, and IE 6.	However if the image is relatively positioned
at the IMG level, the entire image appears.
I think the bug should be reopened, because someone who codes with IE or Opera
might relatively position an element at the anchor level, because the entire image
shows up in those browsers.  I find nothing in the w3c's CSS2 positioning
properties which prohibit relative positioning at the anchor level.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Target Milestone: --- → Future
I think bug 86850, bug 94563 and bug 124825 are duplicate (or at least very
close) of this bug.
*** Bug 124825 has been marked as a duplicate of this bug. ***
Comments from Bug 94563:

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.3+) Gecko/20010809
BuildID:    2001080904

The image drawn by the following code has only the bottom portion of the image
visible.  The layout seems to be taking the entire image into account, but only
draws an amount equal to the current line-height.

<span style="position:relative;"><img src="example.gif"></span>

This is more than a rendering problem, because the DOM tells me that the top of
the image is the top of where the image is visible.

If you specify an *incorrect* height on the IMG tag, it often (but not always)
shows properly with the specified height.  Using the height of the actual image
has no effect.

Reproducible: Always

NOTE: The only difference between the Standard and Quirk layout mode is that the
 Standard mode shows the Span to extend a few pixels below the image, but not
above it into the space "reserved" for it.  (As observed with a background color
on the relatively-placed span)

------- Additional Comment #5 From Kevin McCluskey 2001-10-22 17:48 -------

Specifying an image height of 49 or 51 for the relatively positioned span fixes
the problem. Not specifying a height or using a height of 50 (which is the
actual height of the image) makes the problem appear.

<IMG height=49 src="s_files/example1.gif">


Attached image Image for testcase
Attached file New testcase
This is the testcase from bug 124825.  I could have probably reworked to tc so
I wouldn't need to copy the image over, but at least this tc will not become
stale.
In addition to the new testcase, bug 94563 points to this external testcase:

http://63.140.143.76/Gecko_bugs/Span_img/example_detail.html

bug 94563 was seen on linux, so setting platform and os to all
OS: Windows 98 → All
Hardware: PC → All
*** Bug 94563 has been marked as a duplicate of this bug. ***
Attachment #61408 - Attachment is obsolete: true
This testcase shows the image truncation happening with a:hover.
*** Bug 86850 has been marked as a duplicate of this bug. ***
Sorry about the spam.

remove qawanted and added testcase keywords.
Keywords: qawantedtestcase
Whiteboard: [imglib] DUPME [NEED TESTCASE] → [imglib] DUPME
*** Bug 126014 has been marked as a duplicate of this bug. ***
*** Bug 133036 has been marked as a duplicate of this bug. ***
Summary: Only bottom part of images are displayed. → [rel pos]Only bottom part of images are displayed.
*** Bug 141000 has been marked as a duplicate of this bug. ***
*** Bug 143317 has been marked as a duplicate of this bug. ***
This testcase shows that the problem isn't specific to images, but that text
needs to be entirely outside the bounds to have the problem.  In other words,
if any part of a character is within some bounds, we paint the character and
we're OK, but with images, we use the same bounds to determine what to paint.
Attached patch patch that fixes bug (obsolete) — Splinter Review
This patch fixes the bug.  I'm not sure whether it's right, though.

roc, what's the latest on the bounds of views for frames that have overflowing
children?  (I remember bug 13213, but I'm not sure if that's the latest, and I
also don't want to read the whole thing.)
I think this patch just papers over cracks. If you apply the patch and then
expose just the "sup" area I think you'll find that it's not repainted properly.

We already have bugs addressing this issue, but I don't have bug numbers handy.
The rule is that views must fully contain their child views; this is often
violated for views on inline children of blocks, and it can't easily be fixed
because the mOverflowArea for block-flowed frames is overloaded in a stupid way.
(This problem leads to many bugs in addition to relative-positioned elements not
being painted properly.) Give me a true overflow area rect and all these
problems go away. It's definitely not 1.0 material.
*** Bug 144970 has been marked as a duplicate of this bug. ***
On http://www.fabrice-pascal.de/bugbase/hidepicmoz , only the bottom part of 
the lower picture is visible.  The Picture is placed inside a Div with 

position: relative;
display: inline;

This Bug can be reproduced everytime on every OS running Mozilla RC 2 and lower.
Severity: normal → major
Summary: [rel pos]Only bottom part of images are displayed. → [rel pos]Overflow of relatively positioned elements not painted/repainted
*** Bug 150963 has been marked as a duplicate of this bug. ***
*** Bug 116320 has been marked as a duplicate of this bug. ***
*** Bug 150492 has been marked as a duplicate of this bug. ***
1. scroll the page up and down.
2. note that the characters in the first sentence gets cut off by a few pixels
here and there.
3. if you take focus off the window and then return back, the characters are
drawn back.
*** Bug 163091 has been marked as a duplicate of this bug. ***
*** Bug 170294 has been marked as a duplicate of this bug. ***
Taking bug.  I suspect this will be fixed by bug 174149, which can be fixed
after fixing bug 172896.
Assignee: attinasi → dbaron
Status: REOPENED → NEW
Component: Layout → Layout: R & A Pos
*** Bug 184429 has been marked as a duplicate of this bug. ***
Bug 184429 has a simple testcase -- just having a table with multiple lines of
content in a cell and setting the table to display:inline; position: relative
triggers a nice instance of this bug.
Well, I poked into this and at least I understand what needs to be fixed now,
although I'm not quite sure how to do it.  With some other patches I've attached
recently the combined area / overflow area should now be being set correctly. 
This means we need to start using it when sizing views.  However, right now it's
only stored transiently during reflow.  I suspect this means that views will
need to have a notion of the frame origin distinct from the top-left corner.  Do
they have such a notion now?  The reason we would need it is that we would need
to size and position the view as we're coming out of reflow and computing the
combined area.  However, if we then move a parent element, we might want to
*reposition* the view without resizing it.  We'd thus need to know where the
top-left of the view was relative to the frame origin.

At least, we need that if we want to stick to our current overoptimization of
the rendering tree for footprint.
> I suspect this means that views will
> need to have a notion of the frame origin distinct from the top-left corner.  Do
> they have such a notion now?

Yes they do. We've had this for a long time to handle the situation where a
frame with a view has a child frame which overflows to the top or left.

In fact there is a patch on your review queue which you may find addresses this
issue :-) (see the changes to nsLineLayout)
http://bugzilla.mozilla.org/attachment.cgi?id=108854&action=edit
*** Bug 185386 has been marked as a duplicate of this bug. ***
Is bug 131475 a duplicate of this one?
Adding link to testcase posted to bug 66147 which dbaron speculated was caused
by this bug.

http://www.tagnet.org/castlehill/mozillatest/css2_support_y.html

Jake
*** Bug 187460 has been marked as a duplicate of this bug. ***
*** Bug 188368 has been marked as a duplicate of this bug. ***
Blocks: 197163
*** Bug 198005 has been marked as a duplicate of this bug. ***
*** Bug 198183 has been marked as a duplicate of this bug. ***
*** Bug 201302 has been marked as a duplicate of this bug. ***
My bug 201302 has been marked a duplicate of this, and the basic issue (image
not being displayed) seems to be caused by this bug here (so marking DUP would
be okay), but in addition I noticed that the URL I reported
(http://www.justiz.bayern.de/olgm/wegweiser/allgemein.htm) also causes the tab
to hang when you switch to another tab and back. In the comments of this bug
nothing like that is being reported. Is this another issue or a side effect?
Blocks: 203119
Blocks: 106969
bug 154926 seems somewhat similar
Blocks: 167787
*** Bug 206392 has been marked as a duplicate of this bug. ***
*** Bug 209611 has been marked as a duplicate of this bug. ***
Blocks: 210746
Depends on: 170330
Priority: -- → P1
Attached patch patch? (obsolete) — Splinter Review
This fixes the bug.  I think all of the changes are correct, but they're
probably not all necessary.
Status: NEW → ASSIGNED
Whiteboard: [imglib] DUPME → [patch]
Target Milestone: Future → mozilla1.5beta
This looks pretty good.

We should probably rename nsLineLayout::RelativePositionFrames since it does
more than that...

For lines of inlines, SlideLine() resyncs views using PlaceFrameView which uses
GetOverflowProperty. But inlines never have this property set (StoreOverfow is
only called by blocks). Isn't this going to destroy the correct view size for
overflowing inlines that you set in RelativePositionFrames? It seems like you
should call StoreOverflow on inlines too.
Yes.  I think pretty much all callers of PlaceFrameView are wrong.  But I think
trying to fix them all in one patch might not be easy to understand or review...

I think StoreOverflow is currently used only for absolutely positioned elements.
Ah. Well, I see that it's not your bug, but in some sense this patch will make
things worse because you will set the overflow area correctly and then in some
situations (e.g., when SlideLine is used in a Reflow) it will be mysteriously
lost. I guess I can live with that.

BTW why does nsLineLayout::ReflowFrame actually need to resize the view? won't
your new sync call in RelativePositionFrames always take care of it? (Forgive me
if the answer's obvious, I don't have nsBlockFrame in front of me)
The incremental reflow stuff requires fixing bug 197581 too, FWIW.
One problem is easy to solve, though -- all the callers of PlaceFrameView need
it only to reposition, not resize, so it can pass NS_FRAME_NO_SIZE_VIEW.

I'll investigate your other comments and attach a new patch...
Attached patch patchSplinter Review
This essentially refixes bug 205165, so I should retest that...
Attachment #82970 - Attachment is obsolete: true
Attachment #128211 - Attachment is obsolete: true
Attachment #128281 - Flags: superreview?(roc+moz)
Attachment #128281 - Flags: review?(roc+moz)
I also want to add the following assertion, which should detect any other
problems like this.  I tried a bunch of things and couldn't get it to fire,
though.  I'm not bothering with a new patch just for this:

--- nsContainerFrame.cpp        20 Jul 2003 07:46:42 -0000      1.177
+++ nsContainerFrame.cpp        22 Jul 2003 22:59:30 -0000
@@ -707,12 +707,15 @@ nsContainerFrame::SyncFrameViewAfterRefl
   if (0 == (aFlags & NS_FRAME_NO_SIZE_VIEW)) {
     nsIViewManager* vm = aView->GetViewManager();
  
     // If the frame has child frames that stick outside the content
     // area, then size the view large enough to include those child
     // frames
+    NS_ASSERTION(!(aFrame->GetStateBits() & NS_FRAME_OUTSIDE_CHILDREN) ||
+                 aCombinedArea,
+                 "resizing view for frame with overflow to the wrong size");
     if ((aFrame->GetStateBits() & NS_FRAME_OUTSIDE_CHILDREN) && aCombinedArea)
{
       vm->ResizeView(aView, *aCombinedArea, PR_TRUE);
     } else {
       nsSize frameSize = aFrame->GetSize();
       nsRect newSize(0, 0, frameSize.width, frameSize.height);
       vm->ResizeView(aView, newSize, PR_TRUE);
Comment on attachment 128281 [details] [diff] [review]
patch

OK, that all looks good, including the assertion.

Test it and check it in, I say.
Attachment #128281 - Flags: superreview?(roc+moz)
Attachment #128281 - Flags: superreview+
Attachment #128281 - Flags: review?(roc+moz)
Attachment #128281 - Flags: review+
Fix checked in to trunk, 2003-07-22 17:14 -0700.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago21 years ago
Resolution: --- → FIXED
*** Bug 106969 has been marked as a duplicate of this bug. ***
*** Bug 167787 has been marked as a duplicate of this bug. ***
The removal of the view sizing from nsLineLayout::ReflowFrame broke:
 * the bugzilla edit attachment page (iframe doesn't show up) 
 * http://orbitz.com/ (the search button doesn't show up)

I'm going to back out that change at least until I figure out what's going on.
This might be the cause of bug 213591 then: iframes are not displayed at all.
*** Bug 213783 has been marked as a duplicate of this bug. ***
Confirming fixed in nightly builds of 2003/07/24 of both Mozilla and 
MozillaFirebird. Excellent, thankyou!
*** Bug 219671 has been marked as a duplicate of this bug. ***
*** Bug 112015 has been marked as a duplicate of this bug. ***
*** Bug 93060 has been marked as a duplicate of this bug. ***
*** Bug 210746 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.