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)
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>
Updated•26 years ago
|
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
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?
Updated•26 years ago
|
Assignee: karnaze → pollmann
Status: REOPENED → NEW
Comment 3•26 years ago
|
||
Reassigning frameset bugs to Eric.
Updated•26 years ago
|
QA Contact: beppe → petersen
Comment 4•26 years ago
|
||
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.
Updated•26 years ago
|
Summary: Frames are not honoring visibility settings → {css1} Frames are not honoring CSS visibility property
Whiteboard: [TESTCASE]
Target Milestone: M13 → M16
Comment 5•26 years ago
|
||
Probably unrelated, but below HTML fragment has bad HTML <<hr> inside it. (Note
double <.) Attaching fixed versions as test case and moving to M16.
Comment 6•26 years ago
|
||
Comment 7•26 years ago
|
||
Comment 8•26 years ago
|
||
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...
Comment 9•26 years ago
|
||
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Updated•26 years ago
|
QA Contact: petersen → chrisd
Comment 10•26 years ago
|
||
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.
Updated•26 years ago
|
Summary: {css1} Frames are not honoring CSS visibility property → Frames are not honoring CSS visibility property
Whiteboard: [TESTCASE]
Comment 11•26 years ago
|
||
Do you need this for UI? What blocks you for beta? PDT- for now. Remove if
you have more data.
Whiteboard: [PDT-]
Updated•26 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M16 → M18
Comment 12•26 years ago
|
||
PDT- removed from beta1; nsbeta2 added.
Keywords: nsbeta2
Whiteboard: [PDT-]
Comment 13•26 years ago
|
||
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-]
Comment 14•26 years ago
|
||
Upating [nsbeta-] to read [nsbeta2-] in Status Whiteboard.
Whiteboard: [nsbeta-] → [nsbeta2-]
Comment 15•25 years ago
|
||
Marking nsbeta3-
Comment 16•25 years ago
|
||
Moving bug marked nsbeta3- to Future milestone.
Target Milestone: M18 → Future
Updated•25 years ago
|
Whiteboard: [nsbeta2-][nsbeta3-] → [nsbeta2-][nsbeta3-] relnote-devel
Comment 17•25 years ago
|
||
Should 'visibility' really apply to frame elements?
I would consider this bug a very low priority.
Comment 18•25 years ago
|
||
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
Comment 19•24 years ago
|
||
Bulk reassignin HTML FRAME/IFRAME bugs to Eric.
Assignee: pollmann → evaughan
Status: ASSIGNED → NEW
Comment 20•24 years ago
|
||
Bulk re-assigning all of Eric's HTMLFrame bugs to John.
Assignee: eric → jkeiser
Comment 21•24 years ago
|
||
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"
Comment 22•24 years ago
|
||
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.
Comment 23•23 years ago
|
||
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....
Comment 24•22 years ago
|
||
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
Comment 25•22 years ago
|
||
Per my comments above.
-M
Long live Mozilla.
Status: NEW → RESOLVED
Closed: 26 years ago → 22 years ago
Resolution: --- → WORKSFORME
Updated•7 years ago
|
Product: Core → Core Graveyard
Updated•7 years ago
|
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.
Description
•