The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in mozilla1.5beta

Status

()

Core
Layout: R & A Pos
P1
major
RESOLVED FIXED
16 years ago
9 years ago

People

(Reporter: Ronald Clifford Buckman, Assigned: dbaron)

Tracking

(Blocks: 1 bug, {testcase})

Trunk
mozilla1.5beta
testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [patch], URL)

Attachments

(7 attachments, 3 obsolete attachments)

(Reporter)

Description

16 years ago
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

16 years ago
I'm seeing this on Windows 2000 Build 2001050720

Comment 2

16 years ago
-->imagelib (not image conversion)
Assignee: mjudge → pavlov
Component: Image Conversion Library → ImageLib

Comment 3

16 years ago
Changing status to [imglib], i see this on W2K build 2001050804
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [imglib]

Updated

16 years ago
Whiteboard: [imglib] → [imglib] DUPME

Comment 4

16 years ago
Pav sez: he has a dup should be fixed by 0.9.2
Keywords: qawanted
Target Milestone: --- → mozilla0.9.2

Comment 5

16 years ago
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 → ---

Comment 6

16 years ago
current testcase no longer valid.
not a table specific bug, reassinging to core owner.
Assignee: karnaze → attinasi
Whiteboard: [imglib] DUPME → [imglib] DUPME [NEED TESTCASE]

Comment 7

16 years ago
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
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
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.
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 → ---

Updated

15 years ago
Target Milestone: --- → Future

Comment 10

15 years ago
I think bug 86850, bug 94563 and bug 124825 are duplicate (or at least very
close) of this bug.

Comment 11

15 years ago
*** Bug 124825 has been marked as a duplicate of this bug. ***

Comment 12

15 years ago
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

15 years ago
Created attachment 68881 [details]
Image for testcase

Comment 14

15 years ago
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

15 years ago
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

Comment 16

15 years ago
*** Bug 94563 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Attachment #61408 - Attachment is obsolete: true

Comment 17

15 years ago
Created attachment 68885 [details]
Alternate TC from bug 86850

This testcase shows the image truncation happening with a:hover.

Comment 18

15 years ago
*** Bug 86850 has been marked as a duplicate of this bug. ***

Comment 19

15 years ago
Sorry about the spam.

remove qawanted and added testcase keywords.
Keywords: qawanted → testcase
Whiteboard: [imglib] DUPME [NEED TESTCASE] → [imglib] DUPME

Comment 20

15 years ago
*** 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. ***
(Assignee)

Comment 24

15 years ago
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.
(Assignee)

Comment 25

15 years ago
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.)
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

15 years ago
*** Bug 144970 has been marked as a duplicate of this bug. ***

Comment 28

15 years ago
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.
(Assignee)

Updated

15 years ago
Severity: normal → major
Summary: [rel pos]Only bottom part of images are displayed. → [rel pos]Overflow of relatively positioned elements not painted/repainted
(Assignee)

Comment 29

15 years ago
*** Bug 150963 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 30

15 years ago
*** Bug 116320 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 31

15 years ago
*** Bug 150492 has been marked as a duplicate of this bug. ***

Comment 32

15 years ago
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

15 years ago
*** Bug 163091 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 34

15 years ago
*** Bug 170294 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

15 years ago
Depends on: 174149
(Assignee)

Comment 35

15 years ago
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.
(Assignee)

Comment 38

15 years ago
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.
(Assignee)

Comment 39

15 years ago
(And comment 35 is wrong.)
> 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

15 years ago
*** Bug 185386 has been marked as a duplicate of this bug. ***

Comment 42

15 years ago
Is bug 131475 a duplicate of this one?
(Assignee)

Updated

15 years ago
Blocks: 46117

Comment 43

15 years ago
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. ***

Comment 45

14 years ago
*** 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. ***

Comment 48

14 years ago
Created attachment 117743 [details]
Testcase from Bug 198183
*** Bug 201302 has been marked as a duplicate of this bug. ***

Comment 50

14 years ago
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?
(Assignee)

Comment 51

14 years ago
Another issue.
Blocks: 203119
Blocks: 106969

Comment 52

14 years ago
bug 154926 seems somewhat similar
Blocks: 167787

Comment 53

14 years ago
*** Bug 206392 has been marked as a duplicate of this bug. ***
*** Bug 209611 has been marked as a duplicate of this bug. ***
Blocks: 210746
(Assignee)

Updated

14 years ago
Depends on: 170330
Priority: -- → P1
(Assignee)

Comment 55

14 years ago
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.
(Assignee)

Updated

14 years ago
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.
(Assignee)

Comment 57

14 years ago
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)
(Assignee)

Comment 59

14 years ago
The incremental reflow stuff requires fixing bug 197581 too, FWIW.
(Assignee)

Comment 60

14 years ago
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...
(Assignee)

Comment 61

14 years ago
Created attachment 128281 [details] [diff] [review]
patch

This essentially refixes bug 205165, so I should retest that...
Attachment #82970 - Attachment is obsolete: true
Attachment #128211 - Attachment is obsolete: true
(Assignee)

Updated

14 years ago
Attachment #128281 - Flags: superreview?(roc+moz)
Attachment #128281 - Flags: review?(roc+moz)
(Assignee)

Comment 62

14 years ago
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+
(Assignee)

Comment 64

14 years ago
Fix checked in to trunk, 2003-07-22 17:14 -0700.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago14 years ago
Resolution: --- → FIXED
(Assignee)

Comment 65

14 years ago
*** Bug 106969 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 66

14 years ago
*** Bug 167787 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 67

14 years ago
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

14 years ago
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. ***

Comment 70

14 years ago
Confirming fixed in nightly builds of 2003/07/24 of both Mozilla and 
MozillaFirebird. Excellent, thankyou!
(Assignee)

Comment 71

14 years ago
*** 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.