Closed Bug 35935 Opened 24 years ago Closed 24 years ago

{ib} Invisible paragraphs in spans with CSS relative positioning

Categories

(Core :: Layout, defect, P1)

Product:
Core
Component:
Layout
Platform:
x86
Windows 95
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: steuard+moz, Assigned: waterson)

References

(
URL
)

Details

(Keywords: helpwanted, testcase, Whiteboard: FIX IN HAND)

Attachments

(5 files)

reporter's test case
1.20 KB, text/html
Details
JS animation using "style='position:relative'" and .style property
1.08 KB, text/html
Details
proposed fix
9.31 KB, patch
Details | Diff | Splinter Review
better fix; make sure anonymous block gets relative position styles
11.77 KB, patch
Details | Diff | Splinter Review
one more time, with feeling. too eager to relatively position all anonymous blocks in the last patch
11.80 KB, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (Win95; U)
BuildID:    2000022820

When a block of text is marked with a paragraph tag inside a span with its style 
set to relative positioning, Mozilla does not display its text.  However, it 
seems to have been properly laid out on the screen: hyperlinks in the included 
text are accessible, and the cursor changes shape when it moves over the 
(invisible) text area.

Reproducible: Always
Steps to Reproduce:
1. Open Mozilla
2. Go to the URL http://home.uchicago.edu/~sbjensen/Vanish.html


Actual Results:  The paragraph of text that is above the horizontal line is not 
visible.

Expected Results:  The paragraph should, in fact, be visible.

The following fragment is also available at the URL below.  It is just a 
stripped down version of the sample URL given above.

http://home.uchicago.edu/~sbjensen/Vanish1.html

<HTML>
<BODY>
<SPAN STYLE="position:relative;">

<P>There is supposed to be a paragraph here, but it is not visible.

</SPAN>
</BODY>
</HTML>
I get this too (linuxppc 2000041919). I'm not sure the correct component is
"Compositor" though, maybe parser or HTML Element but I lack the experience to
say for sure.

regression: works okay with netscape 4.72
Confirming on 20000430. Moving -> HTML Element.

Gerv
Status: UNCONFIRMED → NEW
Component: Compositor → HTML Element
Ever confirmed: true
Keywords: testcase
The content model includes the invisible text. The view hierarchy looks OK as 
well. Reassigning to buster.
Assignee: kmcclusk → buster
another {ib} bug, this one's a little different perhaps because it includes a 
relatively positioned span.
Assignee: buster → nisheeth
Priority: P3 → P1
Summary: Invisible paragraphs in spans with CSS relative positioning → {ib} Invisible paragraphs in spans with CSS relative positioning
Target Milestone: --- → M17
Is it legal HTML to put a P inside a SPAN? In principle at least, DIVs enclose 
elements, SPANs enclose sub-element text. If this is bad HTML, it's a lower 
priority (although it may be a common bad thing we want to handle well).
It's not legal HTML.  Inline HTML elements cannot enclose block-level HTML
elements.

This could be a reasonably simple bug - perhaps the Paint method is just not
being called for some reason??
gut feel:  not simple.  although, it might just fall out of the {ib} work 
nisheeth and waterson are working on.
also gut feel: this is a common thing to do. Just look at all the bugs 
designated with {ib}, they're all from real pages.
helpwanted: Can anyone quantify how widespread P in SPAN is on the Internet? If 
we don't fix this "bug" (really, an enhancement for NavQuirks handling), there's 
a simple workaround: fix the !@#$% HTML. ;-> But if the practice is widespread, 
we need to handle it well. The data we're lacking is an understanding of how 
common this is.
Keywords: helpwanted
Blocks: 40246
Accepting bug...
Status: NEW → ASSIGNED
taking
Assignee: nisheeth → waterson
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Ok, this is happening because we go thru a different code path when constructing
a relatively positioned inline frame. We never trip kipp's magic code. My
question (esp. to dbaron) is this:

In the case where we've got to do this split inline-block-inline magic for the
relatively positioned frame, would it be reasonable to create a dummy block
frame that wraps all of the elements, and make *that* be relatively positioned?
I don't think we want to create *three* relatively positioned frames -- do we?
Ok, as a quick sanity check, I tried the following content:

  <html><body>
  <div style="position:relative"><span>a<p>foo</p>b</span></div>
  </html></body>

and

  <html><body>
  <span style="position:relative">a</span>
  <p style="position:relative>foo</p>
  <span style="position:relative">b</span>
  </html></body>

If I play around with the "top" and "left" styles, it seems like both
essentially come up with the same result (so long as top & left are uniformly
applied to all relatively positioned elements). AFAICT (with my amateur
understanding of CSS2), it's 6 one way, half dozen the other...
Just read up on "position:relative", and I'm pretty sure that wrapping
everything in a block is the wrong thing. For one, it will misconstrue the
amount of space taken in the normal flow. So the tricky thing will be to get
something like the following test case right.
To see what the "hole" should look like, remove the "style='position:relative'"
attribute from the span with "id='span'".
With DIVs and SPANs, does the parser do anything funny to make the content model
valid?  (If it does, you can use a DIV for the span and just make it
'display:inline' (or the reverse, like I see in your newest testcase), or mess
with XML stuff.)

Wrapping in a big block sounds like it would mess up:
<block>A <inline>B <inner-block>C</inner-block> D </inline> E </block>

Also, I'm a little suspicious of relative positioning requiring different types
of frames (although I guess that's what the code does) since every type of CSS
"frame" can be relatively positioned...
Attached patch proposed fix — — Splinter Review 

    
    

    
  
So here's a fix; do the same thing for positioned inlines frames that we do for
regular inline frames. Added a parameter to ConstructInlines() that says whether
we we're doing a positioned frame or not.

    
  
Whiteboard: FIX IN HAND

    
    

    
  
Just attached a better fix, looking for r= love.

- augment nsCSSFrameConstructor::ConstructInline to handle relatively positioned
inlines: add an "aIsPositioned" argument that internal logic switches on.

- special case frame construction code to call ConstructInline when building a
relatively positioned inline frame.

- modify html.css to add a :-moz-anonymous-positioned-block style

- modify html atom list to include an atom for it.

Open issues (see "XXXwaterson"):

1. are there other properties (besides top, left, bottom, right) that
:-moz-anonymous-positioned-block needs to inherit?

2. we slam absolute and floated items onto the first inline. any problem with
that?

    
    

    
  
Damn. Botched the last patch by forcing every anonymous block to be relatively
positioned.

    
    

    
  
r=buster, looks fine.


    
    

    
  
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED

    
    

    
  
I'm not sure how to verify this issue. Can the reporter double check this fix ?


    
    

    
  
Marking verified in the Aug 24th build.

Status: RESOLVED → VERIFIED

    
    

    
  
SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.
Component: HTML Element → Layout

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: