Last Comment Bug 79315 - [rel pos]Overflow of relatively positioned elements not painted/repainted
: [rel pos]Overflow of relatively positioned elements not painted/repainted
Status: RESOLVED FIXED
[patch]
: testcase
Product: Core
Classification: Components
Component: Layout: R & A Pos (show other bugs)
: Trunk
: All All
: P1 major with 3 votes (vote)
: mozilla1.5beta
Assigned To: David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
: Chris Petersen
Mentors:
http://members.truepath.com/ron/banne...
: 86850 93060 94563 106969 112015 116320 124825 126014 133036 141000 143317 144970 150492 150963 163091 167787 170294 184429 185386 187460 188368 198005 198183 206392 209611 210746 213783 219671 (view as bug list)
Depends on: 170330 174149
Blocks: 46117 106969 167787 197163 203119 210746
  Show dependency treegraph
 
Reported: 2001-05-07 20:59 PDT by Ronald Clifford Buckman
Modified: 2007-12-10 12:08 PST (History)
44 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Relatively positioned image links (788 bytes, text/html)
2001-12-11 23:20 PST, Ronald Clifford Buckman
no flags Details
Image for testcase (1.10 KB, image/gif)
2002-02-11 09:54 PST, Christopher Whitt
no flags Details
New testcase (516 bytes, text/html)
2002-02-11 10:01 PST, Christopher Whitt
no flags Details
Alternate TC from bug 86850 (278 bytes, text/html)
2002-02-11 10:21 PST, Christopher Whitt
no flags Details
testcase showing the problem isn't specific to images (761 bytes, text/html)
2002-05-09 15:12 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details
patch that fixes bug (3.69 KB, patch)
2002-05-09 16:07 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details | Diff | Splinter Review
testcase - extension to attachment 82955 (2.80 KB, text/html)
2002-08-13 13:57 PDT, Madhur Bhatia
no flags Details
Testcase from Bug 198183 (944 bytes, text/html)
2003-03-19 11:07 PST, CharlesTaylor
no flags Details
patch? (11.43 KB, patch)
2003-07-21 23:12 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details | Diff | Splinter Review
patch (12.11 KB, patch)
2003-07-22 15:38 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
roc: review+
roc: superreview+
Details | Diff | Splinter Review

Description Ronald Clifford Buckman 2001-05-07 20:59:20 PDT
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.
Comment 1 Scott Tran (Wildcard) 2001-05-07 23:53:38 PDT
I'm seeing this on Windows 2000 Build 2001050720
Comment 2 Kathleen Brade 2001-05-08 08:27:04 PDT
-->imagelib (not image conversion)
Comment 3 Terri Preston 2001-05-08 11:06:44 PDT
Changing status to [imglib], i see this on W2K build 2001050804
Comment 4 Gagan 2001-05-16 14:49:15 PDT
Pav sez: he has a dup should be fixed by 0.9.2
Comment 5 Stuart Parmenter 2001-06-05 10:24:26 PDT
over to layout.  this looks like a its related to the css and absolute 
positioning.
Comment 6 anthonyd 2001-11-26 15:32:15 PST
current testcase no longer valid.
not a table specific bug, reassinging to core owner.
Comment 7 rubydoo123 2001-11-26 16:54:39 PST
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
Comment 8 Ronald Clifford Buckman 2001-12-11 23:20:01 PST
Created attachment 61408 [details]
Relatively positioned image links

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.
Comment 9 Ronald Clifford Buckman 2001-12-19 23:01:14 PST
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.
Comment 10 Sébastien Desvignes 2002-02-11 08:54:38 PST
I think bug 86850, bug 94563 and bug 124825 are duplicate (or at least very
close) of this bug.
Comment 11 Christopher Whitt 2002-02-11 09:28:44 PST
*** Bug 124825 has been marked as a duplicate of this bug. ***
Comment 12 Christopher Whitt 2002-02-11 09:50:32 PST
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">


Comment 13 Christopher Whitt 2002-02-11 09:54:25 PST
Created attachment 68881 [details]
Image for testcase
Comment 14 Christopher Whitt 2002-02-11 10:01:47 PST
Created attachment 68882 [details]
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.
Comment 15 Christopher Whitt 2002-02-11 10:11:05 PST
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
Comment 16 Christopher Whitt 2002-02-11 10:17:00 PST
*** Bug 94563 has been marked as a duplicate of this bug. ***
Comment 17 Christopher Whitt 2002-02-11 10:21:11 PST
Created attachment 68885 [details]
Alternate TC from bug 86850

This testcase shows the image truncation happening with a:hover.
Comment 18 Christopher Whitt 2002-02-11 10:26:09 PST
*** Bug 86850 has been marked as a duplicate of this bug. ***
Comment 19 Christopher Whitt 2002-02-11 11:27:59 PST
Sorry about the spam.

remove qawanted and added testcase keywords.
Comment 20 Martin Honnen 2002-02-17 08:52:19 PST
*** Bug 126014 has been marked as a duplicate of this bug. ***
Comment 21 Boris Zbarsky [:bz] 2002-04-13 21:06:01 PDT
*** Bug 133036 has been marked as a duplicate of this bug. ***
Comment 22 Boris Zbarsky [:bz] 2002-04-29 21:31:28 PDT
*** Bug 141000 has been marked as a duplicate of this bug. ***
Comment 23 Boris Zbarsky [:bz] 2002-05-09 14:44:51 PDT
*** Bug 143317 has been marked as a duplicate of this bug. ***
Comment 24 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2002-05-09 15:12:26 PDT
Created attachment 82955 [details]
testcase showing the problem isn't specific to images

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.
Comment 25 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2002-05-09 16:07:26 PDT
Created attachment 82970 [details] [diff] [review]
patch that fixes bug

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.)
Comment 26 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2002-05-10 08:54:03 PDT
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.
Comment 27 R.K.Aa. 2002-05-16 04:43:25 PDT
*** Bug 144970 has been marked as a duplicate of this bug. ***
Comment 28 Fabrice Pascal 2002-05-21 07:38:31 PDT
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.
Comment 29 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2002-06-11 14:56:18 PDT
*** Bug 150963 has been marked as a duplicate of this bug. ***
Comment 30 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2002-06-14 17:14:54 PDT
*** Bug 116320 has been marked as a duplicate of this bug. ***
Comment 31 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2002-07-02 14:43:29 PDT
*** Bug 150492 has been marked as a duplicate of this bug. ***
Comment 32 Madhur Bhatia 2002-08-13 13:57:36 PDT
Created attachment 95161 [details]
testcase - extension to attachment 82955 [details]

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.
Comment 33 R.K.Aa. 2002-08-16 10:06:53 PDT
*** Bug 163091 has been marked as a duplicate of this bug. ***
Comment 34 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2002-09-23 07:06:54 PDT
*** Bug 170294 has been marked as a duplicate of this bug. ***
Comment 35 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2002-10-22 14:55:27 PDT
Taking bug.  I suspect this will be fixed by bug 174149, which can be fixed
after fixing bug 172896.
Comment 36 Boris Zbarsky [:bz] 2002-12-10 09:47:43 PST
*** Bug 184429 has been marked as a duplicate of this bug. ***
Comment 37 Boris Zbarsky [:bz] 2002-12-10 09:48:46 PST
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.
Comment 38 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2002-12-12 21:43:45 PST
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.
Comment 39 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2002-12-12 21:45:21 PST
(And comment 35 is wrong.)
Comment 40 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2002-12-13 13:32:48 PST
> 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
Comment 41 ArronM (:paper) 2002-12-14 11:37:58 PST
*** Bug 185386 has been marked as a duplicate of this bug. ***
Comment 42 Malcolm Rowe 2002-12-15 03:27:39 PST
Is bug 131475 a duplicate of this one?
Comment 43 Jacob Kjome 2002-12-19 23:03:19 PST
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
Comment 44 Boris Zbarsky [:bz] 2003-01-03 01:37:13 PST
*** Bug 187460 has been marked as a duplicate of this bug. ***
Comment 45 Ruslan Ismailov 2003-01-12 00:17:22 PST
*** Bug 188368 has been marked as a duplicate of this bug. ***
Comment 46 Boris Zbarsky [:bz] 2003-03-18 07:17:21 PST
*** Bug 198005 has been marked as a duplicate of this bug. ***
Comment 47 Boris Zbarsky [:bz] 2003-03-19 10:05:58 PST
*** Bug 198183 has been marked as a duplicate of this bug. ***
Comment 48 CharlesTaylor 2003-03-19 11:07:53 PST
Created attachment 117743 [details]
Testcase from Bug 198183
Comment 49 Boris Zbarsky [:bz] 2003-04-09 00:34:17 PDT
*** Bug 201302 has been marked as a duplicate of this bug. ***
Comment 50 Oliver Kluge 2003-04-09 01:13:12 PDT
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?
Comment 51 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-04-09 06:32:39 PDT
Another issue.
Comment 52 Markus Hübner 2003-04-30 04:53:58 PDT
bug 154926 seems somewhat similar
Comment 53 Erik 2003-05-25 22:45:09 PDT
*** Bug 206392 has been marked as a duplicate of this bug. ***
Comment 54 Boris Zbarsky [:bz] 2003-06-16 22:33:43 PDT
*** Bug 209611 has been marked as a duplicate of this bug. ***
Comment 55 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-07-21 23:12:44 PDT
Created attachment 128211 [details] [diff] [review]
patch?

This fixes the bug.  I think all of the changes are correct, but they're
probably not all necessary.
Comment 56 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2003-07-22 07:27:44 PDT
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.
Comment 57 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-07-22 11:33:55 PDT
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.
Comment 58 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2003-07-22 12:55:40 PDT
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)
Comment 59 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-07-22 15:07:57 PDT
The incremental reflow stuff requires fixing bug 197581 too, FWIW.
Comment 60 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-07-22 15:21:30 PDT
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...
Comment 61 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-07-22 15:38:36 PDT
Created attachment 128281 [details] [diff] [review]
patch

This essentially refixes bug 205165, so I should retest that...
Comment 62 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-07-22 16:00:49 PDT
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 63 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2003-07-22 16:53:27 PDT
Comment on attachment 128281 [details] [diff] [review]
patch

OK, that all looks good, including the assertion.

Test it and check it in, I say.
Comment 64 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-07-22 17:15:16 PDT
Fix checked in to trunk, 2003-07-22 17:14 -0700.
Comment 65 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-07-22 17:33:02 PDT
*** Bug 106969 has been marked as a duplicate of this bug. ***
Comment 66 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-07-22 17:34:27 PDT
*** Bug 167787 has been marked as a duplicate of this bug. ***
Comment 67 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-07-23 15:44:33 PDT
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.
Comment 68 Steffen Wilberg 2003-07-23 15:54:13 PDT
This might be the cause of bug 213591 then: iframes are not displayed at all.
Comment 69 Boris Zbarsky [:bz] 2003-07-24 21:22:05 PDT
*** Bug 213783 has been marked as a duplicate of this bug. ***
Comment 70 Brett Donald 2003-07-24 21:35:33 PDT
Confirming fixed in nightly builds of 2003/07/24 of both Mozilla and 
MozillaFirebird. Excellent, thankyou!
Comment 71 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-09-19 23:29:55 PDT
*** Bug 219671 has been marked as a duplicate of this bug. ***
Comment 72 Benjamin Smedberg [:bsmedberg] 2004-02-28 10:36:03 PST
*** Bug 112015 has been marked as a duplicate of this bug. ***
Comment 73 Boris Zbarsky [:bz] 2004-04-24 09:18:00 PDT
*** Bug 93060 has been marked as a duplicate of this bug. ***
Comment 74 Boris Zbarsky [:bz] 2004-04-24 09:21:34 PDT
*** Bug 210746 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.