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)

x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: ed.randall, Unassigned)

References

()

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.
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.