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)
Core
Layout: Positioned
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.
Comment 1•23 years ago
|
||
I'm seeing this on Windows 2000 Build 2001050720
Comment 2•23 years ago
|
||
-->imagelib (not image conversion)
Assignee: mjudge → pavlov
Component: Image Conversion Library → ImageLib
Comment 3•23 years ago
|
||
Changing status to [imglib], i see this on W2K build 2001050804
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [imglib]
Updated•23 years ago
|
Whiteboard: [imglib] → [imglib] DUPME
Pav sez: he has a dup should be fixed by 0.9.2
Keywords: qawanted
Target Milestone: --- → mozilla0.9.2
Comment 5•23 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 → ---
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•23 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
Closed: 23 years ago
Resolution: --- → WORKSFORME
Comment 8•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
Target Milestone: --- → Future
Comment 10•22 years ago
|
||
I think bug 86850, bug 94563 and bug 124825 are duplicate (or at least very close) of this bug.
Comment 11•22 years ago
|
||
*** Bug 124825 has been marked as a duplicate of this bug. ***
Comment 12•22 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•22 years ago
|
||
Comment 14•22 years ago
|
||
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•22 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•22 years ago
|
||
*** Bug 94563 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Attachment #61408 -
Attachment is obsolete: true
Comment 17•22 years ago
|
||
This testcase shows the image truncation happening with a:hover.
Comment 18•22 years ago
|
||
*** Bug 86850 has been marked as a duplicate of this bug. ***
Comment 19•22 years ago
|
||
Sorry about the spam. remove qawanted and added testcase keywords.
Comment 20•22 years ago
|
||
*** Bug 126014 has been marked as a duplicate of this bug. ***
Comment 21•22 years ago
|
||
*** Bug 133036 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Summary: Only bottom part of images are displayed. → [rel pos]Only bottom part of images are displayed.
Comment 22•22 years ago
|
||
*** Bug 141000 has been marked as a duplicate of this bug. ***
Comment 23•22 years ago
|
||
*** Bug 143317 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 24•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
*** Bug 144970 has been marked as a duplicate of this bug. ***
Comment 28•22 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•22 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•22 years ago
|
||
*** Bug 150963 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 30•22 years ago
|
||
*** Bug 116320 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 31•22 years ago
|
||
*** Bug 150492 has been marked as a duplicate of this bug. ***
Comment 32•22 years ago
|
||
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•22 years ago
|
||
*** Bug 163091 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 34•22 years ago
|
||
*** Bug 170294 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 35•22 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
Comment 36•22 years ago
|
||
*** Bug 184429 has been marked as a duplicate of this bug. ***
Comment 37•22 years ago
|
||
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•22 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•22 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•22 years ago
|
||
*** Bug 185386 has been marked as a duplicate of this bug. ***
Comment 42•22 years ago
|
||
Is bug 131475 a duplicate of this one?
Comment 43•22 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
Comment 44•22 years ago
|
||
*** Bug 187460 has been marked as a duplicate of this bug. ***
Comment 45•22 years ago
|
||
*** Bug 188368 has been marked as a duplicate of this bug. ***
Comment 46•21 years ago
|
||
*** Bug 198005 has been marked as a duplicate of this bug. ***
Comment 47•21 years ago
|
||
*** Bug 198183 has been marked as a duplicate of this bug. ***
Comment 48•21 years ago
|
||
Comment 49•21 years ago
|
||
*** Bug 201302 has been marked as a duplicate of this bug. ***
Comment 50•21 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•21 years ago
|
||
Another issue.
Comment 52•21 years ago
|
||
bug 154926 seems somewhat similar
Comment 53•21 years ago
|
||
*** Bug 206392 has been marked as a duplicate of this bug. ***
Comment 54•21 years ago
|
||
*** Bug 209611 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 55•21 years ago
|
||
This fixes the bug. I think all of the changes are correct, but they're probably not all necessary.
Assignee | ||
Updated•21 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•21 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•21 years ago
|
||
The incremental reflow stuff requires fixing bug 197581 too, FWIW.
Assignee | ||
Comment 60•21 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•21 years ago
|
||
This essentially refixes bug 205165, so I should retest that...
Attachment #82970 -
Attachment is obsolete: true
Attachment #128211 -
Attachment is obsolete: true
Assignee | ||
Updated•21 years ago
|
Attachment #128281 -
Flags: superreview?(roc+moz)
Attachment #128281 -
Flags: review?(roc+moz)
Assignee | ||
Comment 62•21 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•21 years ago
|
||
Fix checked in to trunk, 2003-07-22 17:14 -0700.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 21 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 65•21 years ago
|
||
*** Bug 106969 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 66•21 years ago
|
||
*** Bug 167787 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 67•21 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•21 years ago
|
||
This might be the cause of bug 213591 then: iframes are not displayed at all.
Comment 69•21 years ago
|
||
*** Bug 213783 has been marked as a duplicate of this bug. ***
Comment 70•21 years ago
|
||
Confirming fixed in nightly builds of 2003/07/24 of both Mozilla and MozillaFirebird. Excellent, thankyou!
Assignee | ||
Comment 71•21 years ago
|
||
*** Bug 219671 has been marked as a duplicate of this bug. ***
Comment 72•20 years ago
|
||
*** Bug 112015 has been marked as a duplicate of this bug. ***
Comment 73•20 years ago
|
||
*** Bug 93060 has been marked as a duplicate of this bug. ***
Comment 74•20 years ago
|
||
*** 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.
Description
•