Closed
Bug 13743
Opened 26 years ago
Closed 21 years ago
block inside a replaced element not displaying correctly {ib}
Categories
(Core :: Layout: Block and Inline, defect, P2)
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: ludo, Assigned: waterson)
References
()
Details
(Keywords: dom0, testcase, Whiteboard: [Hixie-P4])
Attachments
(2 files)
using 4.61 on the same machine is ok.
Mozilla build 1999091308 just doesn't display anything
Updated•26 years ago
|
Assignee: don → vidur
Component: Browser-General → DOM Level 0
Comment 2•26 years ago
|
||
Updated•26 years ago
|
Whiteboard: [TESTCASE]
Comment 4•26 years ago
|
||
In an attempt to get my bug list in order again, marking all the bugs I have
currently as ASSIGNED.
Comment 5•25 years ago
|
||
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Comment 6•25 years ago
|
||
This works correctly when the Flash plugin is installed correctly (tested on
WinNT). The correct document.writes are coming through.
Comment 7•25 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•25 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•25 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•25 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
Comment 12•25 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•25 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•25 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•25 years ago
|
Status: NEW → ASSIGNED
Updated•23 years ago
|
Component: DOM Level 0 → Layout
QA Contact: desale → ian
Whiteboard: [TESTCASE] → [Hixie-P4]
![]() |
||
Comment 15•22 years ago
|
||
The testcase seems to work for me... are people still seeing this problem?
Component: Layout → Layout: Block & Inline
![]() |
||
Comment 16•21 years ago
|
||
No response, testcase worksforme, so marking worksforme.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•