Frame borders are not being drawn with the native widget colours set by the Windows operating system. The following patch corrects this bug: http://www.geocities.com/SiliconValley/Haven/8120/frame_diff.txt

I added the code provided by Michael Lowe to nsFrameSetFrame.cpp. This is an interim solution until the style system gets them.

Setting all current Open/Normal to M4.

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

This is more css style stuff I believe, chrisd please comment

The system colors CSS thing is bug 1004. Adding as dependency.

Rod, transfer to karnaze (or whoever owns frames these days) once the nsILookAndFeel support is done

The colors have been added to CSS and to the Windows LookAndFeel object. Now the CSS has to be changed. That's it, but this is low priority at the moment.

Changing to M12

Somehow the frame border colours need to be taken from CSS files. Is there a standard for how they are specified?

Hm, logically, the "border" properties applied to the <frame> element would do, wouldn't it?

Grabbing this from Rod and guesstimating a milestone.

Hmm, I'm not familiar with CSS2 system colors and how they are specified/work. Could someone who understands this issue add a small testcase and describe what it should look like? I'd be eternally grateful. :) Thanks! This seems fairly low priority. Marking M16.

CSS2 system colours work just like CSS2 normal colours -- they are just special keywords so you can do things like: border-color: ActiveBorder; I suggest that we use the 'border' property applied to the 'frame' element to decide how to draw the frame borders: frame { border: 3px outset ActiveBorder; } ...or something like that. I guess Pierre or Troy would be able to explain how this would work as far as Mozilla is concerned.

Looks like a quick fix to html.css should suffice, great! Lowering priority, as this is not critical in relation to some of my other bugs. 1) major regressions 2) development blockers 3) crashers and major usability issues 4) cosmetic issues and standards compliance issues This falls in category 4 and seems minor. Moving off to M19.

This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.

donttest

I think there's more going on than just some cosmetics. To me it's a development blocker. (I'm a developer and it blocks my development ^_^) What works is that borders on a frameset gets drawn. But the borders get overdrawn by the frames. You can only see it working when you have an empty frame. Frameborders are not drawn at all. The borders on HTML or BODY of the framecontents are perfectly drawn. What needs to be done is to get the borders on the frames to work. (Could be copied from to border-drawing code of the framesets?) And the framesizes should be decreased by the border sizes. I will attach a testcase which shows these behaviours, and an example of an iframe, where borders are drawn perfectly. I hope that this helps solving this bug/implementing this feature. It can make the frames more attractive, and it'll bring Netscape on par with IE3.

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

*** Bug 82911 has been marked as a duplicate of this bug. ***

Bulk reassignin HTML FRAME/IFRAME bugs to Eric.

Bulk re-assigning all of Eric's HTMLFrame bugs to John.

I think this is working now- the testcases all render with proper borderstyles. Should it be closed?

This is apparently fixed. Border color works for me. Reopen if it's not for you, but given the age of this bug I'll bet it does.

Border colors work for me with the FRAMESET and IFRAME elements, but not with the FRAME element.

I did some testing, and from the vague summary of this bug, I think I can verify that this worksforme too (Mozilla RC1). Keith, can you give a testcase that fails in a recent build?

I've submitted an attachment (a two-framed document with a popular search engine in each frame) that fails on my 2002-04-30 trunk nightly build I'm using on Windows XP. The frames should have a yellow border; check the attachment in Internet Explorer 6 for an idea of the expected results. Of course, bug 3655 must be fixed before this can be fully useful (it's kind of ugly with the frame border/spacing and custom borders).

IMHO this should have a higher severity than "minor", as the border colors are part of CSS 1 and should be applicable to all elements (per http://www.w3.org/TR/REC-CSS1#border )

The funny thing is: The colored borders are there until the frame contents are loaded. The DOM Inspector even confirms that there is a yellow medium outset border in each frame. It even shows smaller dimensions for the BODY-Node than for the FRAME-Node. However, the HTML-Node is at least as big as the FRAME-Node so I guess it paints over the border?

*** Bug 226770 has been marked as a duplicate of this bug. ***

*** Bug 270141 has been marked as a duplicate of this bug. ***

*** Bug 283800 has been marked as a duplicate of this bug. ***

I logged bugzilla bug 270141 back in 2004 also covering this issue and I notice (after reluctantly revisiting the latest version of firefox) that the issue is still outstanding. I will remain disappointed in Firefox until something is finally done to resolve the issue. Being left unresolved for nearly NINE years does not bode well in my books ! My origin issue definition was : The borders rendered around window frames subsequently get zapped by a 100% width table being rendered in the frame. Suspect that both the <frameset framespacing="..."> and <frame style="border: ..."/> attributes are not accurately processed. Good luck with getting this defect resolved... although I'm not going to lose any sleep over it !

The testcases attached here seem to work as intended, so I'm tentatively resolving this as WFM. If this bug is still existent, please attach a new testcase that demonstrates the problem in a modern version of the browser. (Note that <frame> and <frameset> are deprecated as it is.)