Closed Bug 35935 Opened 26 years ago Closed 26 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: 26 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: