13743 - block inside a replaced element not displaying correctly {ib}

Status: RESOLVED WORKSFORME

(Core :: Layout: Block and Inline, defect, P2)

Description

[Ludovic Hirlimann]

using  4.61 on the same machine is ok.
Mozilla build 1999091308 just doesn't display anything

Comment 1

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

This is probably a document.write bug, although there could be problems with the
alternate contents of the object not displaying because it's a mildly unusual
object.

It could be a duplicate of something peterl has, like bug 11141 or bug 11156.
I'm not sure, though.

Comment 2

[Joerg Niemann]

Attachment: A .swf is called via javascript. Thats why the screen stay blamk.

Comment 3

[leger]

Resetting QA contact from leger.

Comment 4

[vidur (gone)]

In an attempt to get my bug list in order again, marking all the bugs I have
currently as ASSIGNED.

Comment 5

[ekrock's old account (dead)]

Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!

Comment 6

[vidur (gone)]

This works correctly when the Flash plugin is installed correctly (tested on 
WinNT). The correct document.writes are coming through.

Comment 7

[vidur (gone)]

I'll attached a reduced test case that simluates the case where we can't find 
the Flash plugin and try to render a table inside the OBJECT. The real problem 
is the way we're constructing a frame for the OBJECT element 
in CantRenderReplacedElement and expecting only a single frame to be returned. 
In this case, the TABLE (a block element) inside the inline OBJECT causes an 
extra block frame to be created, but it's ignored and probably leaked.

Passing along to Troy per our conversation.

Comment 8

[vidur (gone)]

Attachment: reduced test case

Comment 9

[troy]

The problem is that we create an inline frame for the OBJECT which is correct, 
then we start creating child frames. We expect they will all be child frames of 
the inline frame, however, because of changes to the way blocks inside of inline 
are handled, we actually end up with multiple child frames being returned. The 
inline frame plus a table frame.

What happened was that the table is block-level and so it was moved outside of 
the inline frame

Comment 10

[troy]

So the problem is even worse than I had hoped.

The main problem is that the change to how we handle block-level elements 
inside of an inline-level element was made without consideration of all the 
ramifications. For that I'm reassigning to Buster who unfortunately inherited 
this problem

Comment 11

[troy]

There are a few issues here:
1. it's okay that the CantRenderReplacedElement() code doesn't really expect 
more than one frame to be returned, because it just turns around and calls 
ReplaceFrame() to replace the old frame with the new frame(s)

2. the ReplaceFrame() function in nsIFrame is currently defined as having the 
new frame be just a single frame. That's a problem, because we're passing more 
than one

I think the ReplaceFrame() function should be changed and defined so that the 
new frame is a list of frames. That would be consistent with InsertFrames() and 
AppendFrames(), and given that the default implementation of ReplaceFrame() just 
calls RemoveFrame() and then InsertFrames() that would make sense

3. I could have made that API change, but the nsInlineFrame code actually 
implements ReplaceFrame() and it doesn't expect a list of new frames. Neither 
does the nsFrameList function which it calls

4. all of that code get fixed, but now we get to the especially unpleasant part. 
If all of the above worked, then we would be adding an inline frame and an 
anonymous block frame as child frames of the inline frame. That's exactly what 
the code Kipp added is trying to prevent

5. Okay, well if we can't add block frames as child frames of an inline frame, 
then we would need to redo the inline frame that the OBJECT is in (turns out 
that is an A element) as well

Now things get ugly. That restructuring of the frame model is something Kipp 
didn't implement and instead what he would do is call WipeContainingBlock() or 
ReframeContainingBlock()

We can't do that here, though, because if we toss away all the frames and 
recreate them we will still recreate an OBJECT frame and try to load it, find it 
can't be rendered, and endlessly go through this process

The two ways out of this would be either:
1. remember somewhere that the OBJECT frame couldn't be loaded and so when we 
recreate the frames we don't create the OBJECT frame, but instead its alternate 
content

2. we stop relying on ReframeContainingBlock() and WipeContainingBlock() and 
write the code that does a minimal transformation of the tree instead of the 
brure force approach

The third alternative is that we rethink the change that was made to move 
block-level frames outside of inline-level frames and come up with an 
alternative

That was what Kipp used to do, and that led to messy code in the frames

Comment 12

[buster]

chris, since you're all about {ib}, can you take a look at this one?
seemly like we're far enough along now that we should be able to implement 
Troy's first suggested fix.  The trick is figuring out where to store the fact 
that we've already tried to load the object once, and couldn't.  Maybe av could 
suggest something?  Or maybe we save it off as private frame state, similar to 
how we re-populate form data from frame state history using 
RestoreFrameStateFor()?

Comment 13

[buster]

IE5 has a hard time with this too.  Putting an inline around the object, which 
contains a block, is a dubious and thankfully rare thing, so marking this one 
"future"  We simply won't handle this well in our first release, unless someone 
else comes along and wants to fix this.

Comment 14

[buster]

waterson IS ib!
thought I'd assign this over to you, just in case an easy fix for it magically 
popped into your brain.

Comment 15

[Boris Zbarsky [:bzbarsky]]

The testcase seems to work for me... are people still seeing this problem?

Comment 16

[Boris Zbarsky [:bzbarsky]]

No response, testcase worksforme, so marking worksforme.