Closed Bug 131475 Opened 22 years ago Closed 20 years ago

Block-level elements positioned relative to a <span> do not display correctly.

Categories

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

Product:
Core
Component:
Layout: Positioned
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: malcolm-bmo, Assigned: roc)

References

Details

(Keywords: css2)

Attachments

(4 files)

Testcase demonstrating problems rendering relatively positioned iframes.
801 bytes, text/html
Details
How the testcase is displayed in build 2002020803.
10.18 KB, image/png
Details
How the testcase is displayed in 0.9.9 or build 2002031503.
8.46 KB, image/png
Details
Testcase demonstrating that this is actually layout :-)
338 bytes, text/html
Details 
Something appears to have caused a regression in iframe display relatively recently.

If an iframe is positioned relatively to a span, the frame and contents do not
display correctly.  Specifically, the frame may be partially painted, or not
painted at all.  See attached testcase and images (to follow).

cc-ing jst in case this problem is already fixed in his iframe branch.

This worked ok in build 2002020803.  It no longer works in 0.9.9
(2002031104-branch) or 2002031503.  The problem appears regardless of theme and
strict/quirks mode.
Note that the scrollbars for the first iframe are not displayed, and only the
border of the second iframe displays.  The undisplayed parts of the iframes are
transparent.

The first iframe does not appear to be active at all - the text cannot be
scrolled or selected.

In addition, if you right-click and display a context menu over the top of
either of the first two iframes, they do not repaint correctly when the menu is
closed (the area affected is erased to the background color).

It also appears as though something is getting confused when calculating the
menu position - the context menu is offset from the cursor by the position of
the iframe relative to the content area.

The context menu displayed is also the standard context menu.

These problems do not occur with the third iframe.
Keywords: css2, regression
confirmed 2002031403/WXP
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is compositor.
Assignee: jkeiser → kmcclusk
Component: HTMLFrames → Compositor
QA Contact: amar → petersen
Priority: -- → P1
Target Milestone: --- → Future
Open this testcase and try to cover and uncover just the red DIV. You will see
that it doesn't always get painted correctly. This testcase doesn't contain any
IFRAMEs; this is a general problem with relative positioning that has probably
been around for a long time but didn't apply to IFRAMEs because they were being
handled specially. Now that IFRAMEs are handled more like normal content, you
see this problem affecting IFRAMEs too.
My guess is that nsBlockFrame isn't computing its aCombinedArea properly during
reflow in this case, so the span's view isn't being made as big as it should be.
The view needs to enclose all the span's descendant frames.
I was planning to go back and find out exactly which build this problem 
starting occurring in, but it sounds like that isn't going to gain anything if 
we have fixed iframes to behave like other block content.

Does the DIV testcase also exhibit the same problem with context menus? (I 
don't have a build to hand to test atm).

Changing summary from:
<iframe> elements positioned relative to a <span> do not display correctly.
to:
Block-level elements positioned relative to a <span> do not display correctly.

Setting severity to major, since I have no work-around, and nominating for 
mozilla 1.0 and nsbeta1.

Some background: I'm developing an in-house intranet (actually extranet, I 
guess) application for my company.  The requirements I've been given say that 
it must work with IE 5.0 and above.  I'd really like it to work with 
Mozilla/NS, so I've been making sure I test everything across both browsers (or 
to be more precise, I've been developing with Mozilla, and testing with IE).
This bug is now the only thing that would prevent us from using Netscape with 
this application.
Severity: normal → major
Keywords: mozilla1.0, nsbeta1
Summary: <iframe> elements positioned relative to a <span> do not display correctly. → Block-level elements positioned relative to a <span> do not display correctly.
> Does the DIV testcase also exhibit the same problem with context menus? (I
> don't have a build to hand to test atm).

Yes, event handling has just the same problems, now that I've unified view event
handling and rendering :-).

I suspect this won't be hard to fix, it's definitely on the 1.0 radar.
>> Does the DIV testcase also exhibit the same problem with context menus? (I
>> don't have a build to hand to test atm).
> Yes, event handling has just the same problems, now that I've unified view event
> handling and rendering :-).

Are you sure?  I'm using build 2002032003, and I *don't* get the context menu
problem with the DIV testcase, but I do with the IFRAME testcase.  To recap: not
only is the context menu the 'standard' content menu, rather than the frame menu
('Open Frame in New Window', etc), but it is not displayed at the pointer location.

Specifically, the context menu is offset by the position of the iframe origin
relative to the viewport origin.  So, if the iframe origin is below and to the
right of the viewport origin (as it usually will be), the context menu is
displayed above and to the left of the pointer.  If the iframe is scrolled
partially off screen, so that the iframe origin is above and to the right of the
viewport origin, the context menu will be displayed below and to the left of the
pointer.

I'm using 'origin' to mean the top-left corner, btw.
This requires reworking the way block-and-line treats 'combinedArea', and won't
happen for 1.0.
Depends on: 66147
Bummer!  Time to break out the workaround stick.  I'll just have to try to do it
a different way.
nsbeta1- based on comment #12
Keywords: nsbeta1 → nsbeta1-
By "cover and uncover," I presume you mean using another window or something
like that.

If so, WorksForMe using FizzillaCFM/2002071208.
*** Bug 76698 has been marked as a duplicate of this bug. ***
I'll take this.
Assignee: kmcclusk → roc+moz
This is where I'll try to fix relative positioning.

The basic problem is that we're using "overflowArea" (also known as
"combinedArea") for two different things:
A) Sometimes it means "the area containing the bounds of this frame and all its
descendant frames"
B) Sometimes it means "the area containing the bounds of this frame and all its
descendant frames, except that relatively-positioned frames are treated as if
they are in the flow"

Tables assume meaning B. The view system assumes meaning A. Other parts of the
code seem to mostly assume A. Currently we implement B. I think we should switch
that to A and fix tables separately.

In particular, I believe tables should be looking at some sort of "in-flow area"
of each table cell. The in-flow area of a frame F is empty if F is absolutely
positioned, otherwise F's bounds combined with the in-flow areas of F's
children, but NOT displaced if F is relatively positioned.

Note that in bug 170330 I propose that we include clipping in the definition of
overflowArea. Clipping should NOT be applied when calculating in-flow area.
Any comments appreciated. In particular, I wonder if we rely on definition B
anywhere else in layout.
Table cell blocks (the inner cell frame, which is a block frame) should size
just like floats -- they should include the YMost() of the space manager.  I
don't think anything else that wouldn't increase the size of the block should
increase the size of table cells.  It seems, though, that this is already done
in nsBlockFrame::ComputeFinalSize, so I suspect the checking of the overflow
area could just be removed.

(There might be some other cases where such a change would shrink table cells. 
However, I would consider our current behavior in those cases to be a bug.)
Note: Bug 46983 contains an example of a testcase (attachment 91246 [details]) where table
cells are incorrectly growing to contain relatively positioned frames.
ooh, that sounds good. I'll look into it.
Blocks: 46983
I'm curious: should the block-level 'div', even though it's absolutely
positioned, force-close the inline 'span' which acts as its parent, even though
it's relatively positioned?  Does relatively positioning the 'span' magically
turn it into something that can contain block-level elements?  At the moment,
the 'span' is not terminated by the start-tag of the 'div' in attachment 74915 [details]
-- I can submit a modified testcase demonstrating this if need be.  It seems to
me that would have some bearing on the expected outcome of the testcase, even if
it still shows us doing something wrong.  Feel free to smack me if I'm talking
through my hat on this one.
The testcase really shouldn't be using an element called DIV inside an element
called SPAN, since it's not valid HTML and we can do with it what we want.  (We
happen to just leave it as-is.)  However, CSS has no rules for containment, so
an element with 'display: block' can always be inside one with 'display: inline'.
That's right, I keep crossing up the HTML containment rules with the CSS
effects.  Sorry.
I found the bug with relatively positioned inline frames not having the right
overflow. I was on total crack about what the real problem. The layout patch is
in bug 171334 (which contains a much bigger fix for an underlying problem in
views). Basically we just have to re-enable some code that troy disabled 2.5
years ago, and fix the underlying problem that caused him to disable it.
Fortuitously the view synchronization changes that I landed last week make the
underlying problem very easy to fix...
Does that mean that this bug no longer depends upon bug 66147?  Or does it now 
depend upon both 66147 and bug 171334?
OK, I lied. That patch fixes this bug here but it does NOT fix bug 66147. This
bug is about the overflow area of a relatively-positioned element being
incorrect. Bug 66147 is about the overflow area of the relatively-positioned
element's *container* being incorrect.
So Malcolm, my patch fixes your testcase here, but if (for example) you wrapped
the position:relative elements in position:absolute elements with zero height,
you'd see similar problems.
No longer depends on: 66147
I think I understood that :)
Accordingly, removing dependency on bug 66147.
roc: Dependent bug 171334 has been fixed now.  You mentioned (bug 171334 
comment 17) that you had split that patch, and would attach the layout part to 
this bug (which would be a patch to fix this bug).

Is there any chance of doing that now, and getting through r/sr/a for checkin 
to 1.2?
There's a bunch of work on the overflow area that is a bit tangled up now. I'm
leaning towards not landing it for 1.2. For 1.2 the priority is to fix
regressions and this isn't one.
Fair enough, though (strictly speaking) this was originally a regression (in 
the IFRAME case).

(Removing some old keywords too, including 'regression')
Keywords: mozilla1.0, nsbeta1-, regression
Blocks: 206392
No longer blocks: 206392
Why is this listed as a GFX bug? Surely it's a layout bug?
This has actually been fixed by work on other rel-pos bugs.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Component: GFX → Layout: R & A Pos
VERIFIED FIXED in current trunk builds.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: