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

Status: VERIFIED FIXED

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

Description

[Malcolm Rowe]

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.

Comment 1

[Malcolm Rowe]

Attachment: Testcase demonstrating problems rendering relatively positioned iframes.

Comment 2

[Malcolm Rowe]

Attachment: How the testcase is displayed in build 2002020803.

Comment 3

[Malcolm Rowe]

Attachment: How the testcase is displayed in 0.9.9 or build 2002031503.

Comment 4

[Malcolm Rowe]

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.

Comment 5

[Aaron Kaluszka]

confirmed 2002031403/WXP

Comment 6

[Boris Zbarsky [:bzbarsky]]

This is compositor.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Testcase demonstrating that this is actually layout :-)

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.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 9

[Malcolm Rowe]

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.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

> 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.

Comment 11

[Malcolm Rowe]

>> 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.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This requires reworking the way block-and-line treats 'combinedArea', and won't
happen for 1.0.

Comment 13

[Malcolm Rowe]

Bummer!  Time to break out the workaround stick.  I'll just have to try to do it
a different way.

Comment 14

[Kevin McCluskey (gone)]

nsbeta1- based on comment #12

Comment 15

[Greg K.]

By "cover and uncover," I presume you mean using another window or something
like that.

If so, WorksForMe using FizzillaCFM/2002071208.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

*** Bug 76698 has been marked as a duplicate of this bug. ***

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'll take this.

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Any comments appreciated. In particular, I wonder if we rely on definition B
anywhere else in layout.

Comment 20

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.)

Comment 21

[Malcolm Rowe]

Note: Bug 46983 contains an example of a testcase (attachment 91246 [details]) where table
cells are incorrectly growing to contain relatively positioned frames.

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

ooh, that sounds good. I'll look into it.

Comment 23

[Eric A. Meyer (dead account)]

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.

Comment 24

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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'.

Comment 25

[Eric A. Meyer (dead account)]

That's right, I keep crossing up the HTML containment rules with the CSS
effects.  Sorry.

Comment 26

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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...

Comment 27

[Malcolm Rowe]

Does that mean that this bug no longer depends upon bug 66147?  Or does it now 
depend upon both 66147 and bug 171334?

Comment 28

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 29

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 30

[Malcolm Rowe]

I think I understood that :)
Accordingly, removing dependency on bug 66147.

Comment 31

[Malcolm Rowe]

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?

Comment 32

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 33

[Malcolm Rowe]

Fair enough, though (strictly speaking) this was originally a regression (in 
the IFRAME case).

(Removing some old keywords too, including 'regression')

Comment 34

[Brett Donald]

Why is this listed as a GFX bug? Surely it's a layout bug?

Comment 35

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This has actually been fixed by work on other rel-pos bugs.

Comment 36

[Malcolm Rowe]

VERIFIED FIXED in current trunk builds.