[BLOCK] <object> in inline containing block does not display. {ib}

VERIFIED FIXED in M17

Status

()

Core
Layout
P3
normal
VERIFIED FIXED
18 years ago
16 years ago

People

(Reporter: Sebastian Späth, Assigned: Chris Waterson)

Tracking

Trunk
x86
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fix in hand, URL)

Attachments

(4 attachments)

(Reporter)

Description

18 years ago
Seeing in build 12/16 on Linux

Page http://openprojects.nu contains following lines:
  <A href="about.html">
  <OBJECT>
  <H2>About</H2>
  </OBJECT>
  </A>

When loading a box [object] appears and disappears, but then nothing but a
transparent space shows up where the object should be. It does work as a link as
well.
HTML validator shows the page as strict 4.0 compatible, is <object> not yet
implemented?
(Reporter)

Comment 1

18 years ago
Oops, sorry for the typo in former post:
 It does *not* work as a link!

Updated

18 years ago
Assignee: rickg → kipp

Comment 2

18 years ago
This is well formed and correct as far as the parsing engine is concerned. It
appears to be a layout bug.
Blocks: 7954
Summary: <OBJECT> embedded in <a href="..."> does not work as link → <object> in inline containing block does not display. {ib}
The problem occurs if there is a CSS block inside the object and the object
is stored in an inline element.

e.g.:
   <span><object><span style="block"> should show </span></object></span>
...will not display.

A simple test case is here:
   http://www.bath.ac.uk/%7Epy8ieh/m/object-noattr.html

Comment 4

18 years ago
mass moving all Kipp's pre-beta bugs to M15.  Nisheeth and I will
prioritize these and selectively move high-priority bugs into M13 and M14.
See also these test cases:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/object-unknown.html
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/object-broken.html
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/object-noattr.html
They demonstrate bug 797, bug 15019 and bug 22047 (this one) respectively, see
also bug 678.

Petersen: I'm the QA contact for HTML 'alt text' bugs, if you think that the
object elements' alternate content classifies as 'alt text' then feel free to
put me in as QA contact for this bug.

Updated

18 years ago
Summary: <object> in inline containing block does not display. {ib} → [BLOCK] <object> in inline containing block does not display. {ib}

Comment 6

18 years ago
This is kind of weird.  Ian's test case 
http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/object-noattr.html
works perfectly on Linux build 2000020708 - but if I change the
<span style="display:block"> back to <h2> (as in original bug report), the bug 
is back.

See for yourself - the modified test is at
http://www.netppl.fi/%7esairwas/tests/mozillabug-22037.html

This also occurs on WinNT4 SP6, build 2000020817 - so I'm changing OS to All.
OS: Linux → All

Comment 7

18 years ago
Updating the URL field while I'm there.
My test case doesn't work perfectly on Win32 build of 2000021808:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/object-noattr.html

(Antti: your test case is coming up "403 Forbidden".)

Comment 9

18 years ago
mine! mine mine mine!  all mine!  whoo-hoo!
Assignee: kipp → buster
(Reporter)

Comment 10

18 years ago
Could it be, that this is a manifestation of bug 28553? Citing a comment from there:
>It looks like the primary frame is not found because of a side effect of a
>change Kipp made in how he handles blocks within inlines.
>[...]
>For example, for something like this: <SPAN>Some text <DIV>Nested div</DIV>
>more text</SPAN>

Comment 11

18 years ago
moving all buster m15 bugs to m16.
Target Milestone: M15 → M16

Comment 12

18 years ago
nisheeth is now working on {ib} bugs
Assignee: buster → nisheeth

Comment 13

18 years ago
Accepting bug...
Status: NEW → ASSIGNED

Updated

18 years ago
Blocks: 40246
(Assignee)

Comment 14

18 years ago
I think this may just be a control-flow issue in 
nsCSSFrameConstructor::ConstructFrameByTag(). It looks like in the case of the 
<object> tag, we never recurse to build any of its children. Dumping the frame 
model confirms this, showing no frames ever got constructed beneath the inline 
frame for the object.
(Assignee)

Comment 15

18 years ago
Created attachment 9035 [details]
reduced test case
The children of an OBJECT element should only be displayed if the object cannot
be displayed.  I believe that works in most cases (but not sure).  So the
problem could be in the logic that decides when to use the contents, or
something...
(Assignee)

Comment 17

18 years ago
taking
Assignee: nisheeth → waterson
Status: ASSIGNED → NEW
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

18 years ago
Target Milestone: M16 → M17
(Assignee)

Comment 18

18 years ago
Created attachment 10812 [details] [diff] [review]
proposed fix; add SplitToContainingBlock() method, invoke from CantRenderReplacedFrame().
(Assignee)

Comment 19

18 years ago
nisheeth: yet another block-in-inline bug. can you r=?
(Assignee)

Comment 20

18 years ago
Noting fix in hand, awaiting review. Nominating for nsbeta2 on the basis that 
it will cause pages to render incorrectly if a user doesn't have a plugin 
installed. It is common practice to use the text inside an <object> or <embed> 
tag to give a user plugin download instructions (or provide other alternate 
information) if the plugin cannot be downloaded.
Keywords: nsbeta2
Whiteboard: fix in hand
(Assignee)

Comment 21

18 years ago
Created attachment 10948 [details]
more thorough test case
(Assignee)

Comment 22

18 years ago
Created attachment 10949 [details] [diff] [review]
more thorough patch
(Assignee)

Comment 23

18 years ago
Here's what the patch does.

1. In the initial state, you've got a block frame B that contains a bunch of
inline frames eventually winding down to the <object> frame o 

       A-->B-->C
           |
           a-->1-->a'
               |
               b-->2-->b'
                   |
                   o

2. The object frame o gets split into the left inlines (o), the block frames
(O), and the right inlines (o'). 

               o O o'

3. We call SplitToContainingBlock(), which will split 2 as follows. 

               .--------.
              /          \
         b-->2   2*  2'   b'
             |   |   |
             o   O   o'

Note that 2 gets split into 2* and 2', which correspond to the anonymous block
and inline frames, respectively. Furthermore, note that 2 still refers to b' as
its next sibling, and that 2' does not. If 2 has a continuation frame, then
we'll break that link now, as well.

4. We recurse again to split 1. At this point, we'll break the link between 2
and b', and make b' be the next sibling of 2'. 

               .-----------.
              /             \
         a-->1      1*  1'   a'
             |      |   |
             b-->2  2*  2'-->b'
                 |  |   |
                 o  O   o'

As with 2, 1 retains a' as its next sibling. 

5. When we hit B, the recursion terminates. We now insert 1* and 1' immediately
after 1, resulting in the following frame model. This is done using the "normal"
frame insertion mechanism, nsIFrame::InsertFrames(), which properly recomputes
the line boxes. 

       A-->B-->C
           |
           a-->1------>1*-->1'-->a'      
               |       |    |
               b-->2   2*   2'-->b'
                   |   |    |
                   o   O    o'

Since B is a block, it is allowed to contain both block and inline frames, so we
can let 1* and 1' be "real siblings" of 1.

(Assignee)

Comment 24

18 years ago
fix checked in, r=nisheeth
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Reporter)

Comment 25

18 years ago
Testcase works, original case works, marking verified, but:
When you look at the original case (see the line below) at
http://openprojects.nu you will get links now with a mouse pointer being a
caret(?) and not a hand. Is this correct?

<A href="about.html"> <OBJECT> <H2>About</H2> </OBJECT> </A>
Status: RESOLVED → VERIFIED
(Assignee)

Comment 26

18 years ago
Well, I'd say that sounds wrong to me. Would you mind opening another {ib} bug
on that case?

Comment 27

17 years ago
[parenthetic note: the last comment about 'caret' over link if %block; content 
was ultimately filed as bug 54801, if nowhere else, but it appears to be fixed]
SPAM. HTML Element component is deprecated, changing to Layout component. See
bug 88132 for details.
Come on Bugzilla, you can do it...
Component: HTML Element → Layout
You need to log in before you can comment on or make changes to this bug.