All users were logged out of Bugzilla on October 13th, 2018

block inside a replaced element not displaying correctly {ib}

RESOLVED WORKSFORME

Status

()

P2
normal
RESOLVED WORKSFORME
19 years ago
15 years ago

People

(Reporter: ludo, Assigned: waterson)

Tracking

({dom0, testcase})

Trunk
Future
x86
Linux
dom0, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Hixie-P4], URL)

Attachments

(2 attachments)

(Reporter)

Description

19 years ago
using  4.61 on the same machine is ok.
Mozilla build 1999091308 just doesn't display anything
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.

Updated

19 years ago
Assignee: don → vidur
Component: Browser-General → DOM Level 0

Comment 2

19 years ago
Created attachment 2895 [details]
A .swf is called via javascript. Thats why the screen stay blamk.

Updated

19 years ago
Whiteboard: [TESTCASE]

Updated

19 years ago
QA Contact: leger → desale

Comment 3

19 years ago
Resetting QA contact from leger.

Comment 4

19 years ago
In an attempt to get my bug list in order again, marking all the bugs I have
currently as ASSIGNED.
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase

Comment 6

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

Comment 7

19 years ago
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.
Assignee: vidur → troy
Status: ASSIGNED → NEW
Summary: only the background is displayed → block inside a replaced element not displaying correctly

Comment 8

19 years ago
Created attachment 6239 [details]
reduced test case

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 9

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

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

19 years ago
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
Assignee: troy → buster
Status: ASSIGNED → NEW

Updated

19 years ago
Target Milestone: M17

Updated

19 years ago
Status: NEW → ASSIGNED
Priority: P3 → P2

Comment 12

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

18 years ago
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.
Target Milestone: M17 → Future

Comment 14

18 years ago
waterson IS ib!
thought I'd assign this over to you, just in case an easy fix for it magically 
popped into your brain.
Assignee: buster → waterson
Status: ASSIGNED → NEW
Summary: block inside a replaced element not displaying correctly → block inside a replaced element not displaying correctly {ib}
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Keywords: dom0
Component: DOM Level 0 → Layout
QA Contact: desale → ian
Whiteboard: [TESTCASE] → [Hixie-P4]
The testcase seems to work for me... are people still seeing this problem?
Component: Layout → Layout: Block & Inline
No response, testcase worksforme, so marking worksforme.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.