Closed Bug 287087 Opened 20 years ago Closed 3 years ago

Using a border with nested frames results in only 1 border and content/margin/padding overwrite

Categories

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

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: ed.randall, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1


Ref. http://www.w3.org/TR/CSS1#formatting-model the gecko formatting/box model
implementation results in unexpected (unacceptable) rendering behaviour when
using nested frames.

If a margin is not specified, the border of the outermost frameset is shown
correctly, but it overwrites the margin, border, padding and content of any
inner nested frames and framesets.

If a margin is specified then it and the border are not rendered correctly on
the right and bottom of the outer frameset.

Compare the following test code using a Gecko/Mozilla/Firefox browser and then
Internet Explorer.
Notice how the "TOP", "BOTTOM", "LEFT" and "RIGHT" content text are truncated in
Gecko, but always shown in IE.  

IE seems to ignore the margin and padding settings though.

Specifying a DTD affects the behaviour of Internet Explorer slightly (to no
significant detriment in any situation) but Gecko always behaves the same way.


Reproducible: Always

Steps to Reproduce:
1. Save the files frameset.html and frame2.html below to disk.
2. Open frameset.html in browser.

-----File:frameset.html -----
<HTML>
<HEAD>
<TITLE></TITLE>
</HEAD>
<FRAMESET FRAMEBORDER="" STYLE="border-width:20px; border-color:black;
border-style:dashed; margin:10px; padding:5px;"
          MARGINWIDTH="0" MARGINHEIGHT="0"
          ROWS="200,*">
    <FRAME SRC="frame2.html"
           FRAMEBORDER="0" STYLE="border-width:15px; border-color:brown;
border-style:dotted; margin:10px; padding:5px;"
           MARGINWIDTH="0" MARGINHEIGHT="0"/>

    <FRAMESET FRAMEBORDER="0" STYLE="border-width:20px; border-color:magenta;
border-style:double; margin:10px; padding:5px;"
              MARGINWIDTH="0" MARGINHEIGHT="0"
              ROWS="200,*">

        <FRAME SRC="frame2.html"
               FRAMEBORDER="0" STYLE="border-width:10px; border-color:red;
border-style:dotted; margin:10px; padding:5px;"
               MARGINWIDTH="0" MARGINHEIGHT="0"/>

        <FRAME SRC="frame2.html"
               FRAMEBORDER="0" STYLE="border-width:10px; border-color:orange;
border-style:dotted; margin:10px; padding:5px;"
               MARGINWIDTH="0" MARGINHEIGHT="0"/>
    </FRAMESET>


</FRAMESET>
</HTML>
----- end of frameset.html -----

----- File: frame2.html -----
<HTML>
<HEAD>
<TITLE></TITLE>
</HEAD>

<BODY BGCOLOR="cyan">
<TABLE WIDTH="100%" HEIGHT="100%" BORDER="1">
<TR>
<TD ALIGN="CENTER" VALIGN="TOP" COLSPAN="2">TOP</TD>
</TR><TR>
<TD ALIGN="LEFT" WIDTH="50%">LEFT</TD>
<TD ALIGN="RIGHT" WIDTH="50%">RIGHT</TD>
</TR><TR>
<TD ALIGN="CENTER" VALIGN="BOTTOM" COLSPAN="2">BOTTOM</TD>
</TR>
</TABLE>
</BODY>
</HTML>
----- end of frame2.html -----


Actual Results:  
Only see 1 border, that specified by the outer frameset.
Content of each frame is clipped by the outer border.

Expected Results:  
Borders for each frame neatly nested within one another.
dup of bug 155594 / bug 209476?
Bug 155594 is similar but uses FRAMEBORDER=1, notice that I have FRAMEBORDER=0.

Bug 209476 is about the background color fill overwriting the border, this is
the other way around, the outermost border overwrites the borders and contents
of inner nested frames since they do not seem to take account of the reduced
size available due to their enclosing frames.

From bug 155594 comment 2:

"confirmed; the frameborder="0" on the outer frameset forces border="0" on all
descendants"
Is this an issue in a current build?  I believe we've disabled rendering of CSS
borders on frames/framesets (which can't really be described in CSS in any case).
Yes.

Just so you can see how awful this is, I've uploaded screenshots of the
behaviour in both Firefox and IE to http://www.ingenotech.com/tmp/mozilla_287087/
Also you can click on the frameset.html file there and see it first-hand for
yourself.
At my day job our CTO refuses to officially allow us to spend time supporting
anything but Internet Explorer because of issues such as this.  Naturally
unoffically we continue to do so, but this one is almost impossible to work
around without radically restructuring the way our pages are generated.
Ed, that's Firefox 1.0.2.  That's using a Gecko from April 2004.

Could you possibly test a current trunk Firefox or Mozilla build and see what
the rendering looks like?
Firefox 1.04 does the same thing. Use the following code to test:

<frameset frameborder="no" rows="33%, 67%">
<frame src="http://www.mozilla.org"></frame>
<frameset rows="50%,50%" frameborder="yes">
	<frame src="http://www.mozilla.org"></frame>
	<frame src="http://www.mozilla.org"></frame>
</frameset>
</frameset>

This should make one bar that resizes the second and third mozilla.org frames,
however the frameborder="no" on the first frameset seems to set all children
framesets to frameborder="no".
> Firefox 1.04 does the same thing.

See comment 6.  1.0.4 is a security update.  It has no substantive layout engine
changes from 1.0.

In any case, that testcase has nothing to do with this bug as originally reported...
(In reply to comment #6)
> Ed, that's Firefox 1.0.2.  That's using a Gecko from April 2004.
> 
> Could you possibly test a current trunk Firefox or Mozilla build and see what
> the rendering looks like?


I can confirm that, using a -current build, the broken borders 
are no longer there; In fact, there are no borders there at all.
This is marginally (pun not intended) better than the current situation
but doesn't really address the issue, we have a layout which uses borders
on frames to get its "look" and that look is still broken unfortunately!

I don't understand the logic behind the comment "we've disabled rendering of CSS
borders on frames/framesets (which can't really be described in CSS in any
case)."  Borders on frames make perfect sense and can and are being described 
in CSS by many people.  They just look bad in Mozilla/Gecko because the
implementation is broken.  Where else would you propose I place all of my
border-specific settings in a frame-based layout?  Do I have to encapsulate the
content of each and every page with a table and set the border there?    Maybe
the servlet/XSL framework I'm using isn't the most flexible, but I can either
apply the border I want in only one place (the frame) or modify every single
template (~200+ files) in the application - definately not on the cards!
Meanwhile, in the domain of the evil empire, it just works as-is.   We have a
management apparently hell bent on supporting IE-only, this adds fuel to their fire.
You can see a screenshot of the rendering with -current at
http://www.ingenotech.com/tmp/mozilla_287087/firefox-current-287087.jpg

There are no border decorations whatsoever, and the rendered area is offset
towards the bottom-right resulting in cropping along the bottom-right and
whitespace along the top-left.
> Borders on frames make perfect sense and can and are being described 
> in CSS by many people.

They act nothing like CSS borders (the simplest example is that they are shared
by multiple frames, but there are other pretty fundamental differences).  There
is no way to implement applying CSS to them without violating the CSS specification.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core

Marking this as Resolved > Worksforme since the issue no longer is reproducible on the latest versions of Firefox Nightly 95.0a1 (2021-10-18), beta 94.0b7 or release 93.0 on Windows 10.
If anyone can still reproduce the issue either re-open it or file a new one.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.