Closed Bug 9109 Opened 26 years ago Closed 22 years ago

Frames are not honoring CSS visibility property

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect, P3)

All
Other
defect

Tracking

()

RESOLVED WORKSFORME
Future

People

(Reporter: slogan, Assigned: john)

References

Details

(Keywords: css2, relnote, testcase, Whiteboard: [nsbeta2-][nsbeta3-] relnote-devel)

Attachments

(2 files, 1 obsolete file)

Frames are not honoring visibility settings as I have been told they should. The intent of the following HTML is to hide the FRAME with id "session", but it does not work: <HTML> <STYLE> #warper {position:relative; visibility:visible} #session {position:relative; visibility:hidden} #editor {position:relative; visibility:visible} </STYLE> <TITLE>Test Visibility</TITLE> <FRAMESET ROWS="20%, *, 80%"> <FRAME ID="warper" NAME="imwarper" SRC="http://www.w3.org" WIDTH="370" NORESIZE="true" > <FRAME ID="session" NAME="imsession" SRC="http://www.mozilla.org" WIDTH="370" > <FRAME ID="editor" NAME="imeditor" SRC="http://www.netscape.com" WIDTH="370"> </FRAMESET> </HTML> Here is an experiment, using DIVs, which seems to work however. <HTML> <STYLE> #warper {position:relative; visibility:visible} #session {position:relative; visibility:hidden} #editor {position:relative; visibility:visible} </STYLE> <TITLE>Test Visibility</TITLE> <BODY> <DIV ID="warper"> <iframe SRC="http://www.w3.org"> </iframe> <hr> </DIV> <DIV ID="session"> <iframe SRC="http://www.mozilla.org"> </iframe> <hr> </DIV> <DIV NAME="editor"> <iframe SRC="http://www.netscape.com"> </iframe> <<hr> </DIV> </BODY> </HTML>
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → REOPENED
The HTML I presented in the bug report still does not behave as I was told it should. Was there a problem with it? Or how I was using the visibility style?
Resolution: WORKSFORME → ---
Clearing WorksForMe resolution since this bug has been re-opened.
Assignee: karnaze → pollmann
Status: REOPENED → NEW
Reassigning frameset bugs to Eric.
QA Contact: beppe → petersen
After careful consideration, I've decided that I probably won't get this bug in for M12. Currently I have nearly 50 bugs scheduled for M13, so there is a possibility that this bug may need to be moved out farther still.
Summary: Frames are not honoring visibility settings → {css1} Frames are not honoring CSS visibility property
Whiteboard: [TESTCASE]
Target Milestone: M13 → M16
Probably unrelated, but below HTML fragment has bad HTML <<hr> inside it. (Note double <.) Attaching fixed versions as test case and moving to M16.
Keywords: css1
Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz} radars should now be considered deprecated in favour of keywords. I am *really* sorry about the spam...
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
QA Contact: petersen → chrisd
Changing keyword from CSS1 to CSS2 (visibility is a CSS2 property). Also, adding beta1 keyword. Although there is a lack of information to validate, I believe that the 'visibility' CSS2 property falls in the beta criteria.
Keywords: css1beta1, css2
Summary: {css1} Frames are not honoring CSS visibility property → Frames are not honoring CSS visibility property
Whiteboard: [TESTCASE]
Do you need this for UI? What blocks you for beta? PDT- for now. Remove if you have more data.
Whiteboard: [PDT-]
Status: NEW → ASSIGNED
Target Milestone: M16 → M18
PDT- removed from beta1; nsbeta2 added.
Keywords: nsbeta2
Whiteboard: [PDT-]
Putting on [nsbeta2-] radar. rickg would like to see this fixed, but would not hold PR2 for it. Adding nsbeta3 keyword to get back into nomination radar down the line if not fixed by 5/16.
Keywords: nsbeta3
Whiteboard: [nsbeta-]
Upating [nsbeta-] to read [nsbeta2-] in Status Whiteboard.
Whiteboard: [nsbeta-] → [nsbeta2-]
Keywords: relnote
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]
Marking nsbeta3-
Moving bug marked nsbeta3- to Future milestone.
Target Milestone: M18 → Future
Whiteboard: [nsbeta2-][nsbeta3-] → [nsbeta2-][nsbeta3-] relnote-devel
Should 'visibility' really apply to frame elements? I would consider this bug a very low priority.
Netscape's standard compliance QA team reorganised itself once again, so taking remaining non-tables style bugs. Sorry about the spam. I tried to get this done directly at the database level, but apparently that is "not easy because of the shadow db", "plus it screws up the audit trail", so no can do...
QA Contact: chrisd → ian
Bulk reassignin HTML FRAME/IFRAME bugs to Eric.
Assignee: pollmann → evaughan
Status: ASSIGNED → NEW
Blocks: 104166
Bulk re-assigning all of Eric's HTMLFrame bugs to John.
Assignee: eric → jkeiser
this bug came is in Version 0.9.9 again! page looked good in 0.9.8: <iframe style="position: absolute; top: -100; left: -100; width: 1; height: 1; visibility:hidden" id=clMICommFrm name="clMICommFrm"></iframe> 0.9.9 shows them ignoring "visibility: hidden"
Interesting, now the testcase seems to almost work. The frame is hidden (not its border), but if I drag the border to expand the hidden frame; the frame isn't shown.
So.. is the problem that the borders of the middle frame is still visible? The frame is not painting itself, correctly, per the visibility setting....
Attached file Valid simple testcase
This bug is either invalid or worksforme. Frames ARE honoring the visibilty property. The CSS2 spec states that visibility: hidden elements should affect layout but not actually render their content. If you look at the testcase I'm attaching here, that is exactly what happens. At least, that's what happens on Mozilla 1.4final Win2K. -M
Attachment #3776 - Attachment is obsolete: true
Per my comments above. -M Long live Mozilla.
Status: NEW → RESOLVED
Closed: 26 years ago22 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: