The big frame holding all the content in this frameset has marginwidth=10, but there is no margin actually being applied.

I've fixed it so marginwidth, marginheight are correctly passed to the <frame> document. I can't verify it on this URL, because it is now crashing in javascript. JS_GetPrivate(JSContext * 0x012423c0, JSObject * 0x016cb570) line 431 + 4112 bytes GetHTMLDocumentProperty(JSContext * 0x012423c0, JSObject * 0x016cb570, long 23900988, long * 0x0012f85c) line 87 + 14 bytes js_Interpret(JSContext * 0x012423c0, long * 0x0012f9c0) line 2229 + 37 bytes js_Execute(JSContext * 0x012423c0, JSObject * 0x016ca0a0, JSScript * 0x0125b840, JSFunction * 0x00000000, JSStackFrame * 0x00000000, int 0, long * 0x0012f9c0) line 815 + 13 bytes JS_EvaluateUCScriptForPrincipals(JSContext * 0x012423c0, JSObject * 0x016ca0a0, JSPrincipals * 0x00000000, unsigned short * 0x016de870, unsigned int 3342, char * 0x012c99e0, unsigned int 7, long * 0x0012f9c0) line 2323 + 27 bytes nsJSContext::EvaluateString(nsJSContext * const 0x01242380, const nsString & {" <!-- // CREATE NEW FRAME OBJECT function frameObject (name, link) { this.name = name; partialString = ''; if ("}, char * 0x012c99e0, unsigned int 7, nsString & {""}, int * 0x0012f9ec) line 91 + 64 bytes HTMLContentSink::EvaluateScript(nsString & {" <!-- // CREATE NEW FRAME OBJECT function frameObject (name, link) { this.name = name; partialString = ''; if ("}, int 7) line 2423 + 32 bytes HTMLContentSink::ProcessSCRIPTTag(const nsIParserNode & {...}) line 2530 + 25 bytes HTMLContentSink::AddLeaf(HTMLContentSink * const 0x012cf9e0, const nsIParserNode & {...}) line 1880 + 12 bytes CNavDTD::AddLeaf(const nsIParserNode & {...}) line 2302 + 22 bytes CNavDTD::HandleScriptToken(nsCParserNode & {...}) line 1060 + 12 bytes CNavDTD::OpenContainer(const nsIParserNode & {...}, int 1) line 2128 + 12 bytes CNavDTD::HandleDefaultStartToken(CToken * 0x012cab70, nsHTMLTag eHTMLTag_script, nsIParserNode & {...}) line 781 + 14 bytes CNavDTD::HandleStartToken(CToken * 0x012cab70) line 874 + 23 bytes NavDispatchTokenHandler(CToken * 0x012cab70, nsIDTD * 0x01257870) line 261 + 12 bytes CTokenHandler::operator()(CToken * 0x012cab70, nsIDTD * 0x01257870) line 80 + 14 bytes CNavDTD::HandleToken(CNavDTD * const 0x01257870, CToken * 0x012cab70, nsIParser * 0x012ced00) line 550 + 18 bytes CNavDTD::BuildModel(CNavDTD * const 0x01257870, nsIParser * 0x012ced00, nsITokenizer * 0x01257e50) line 478 + 20 bytes nsParser::BuildModel() line 718 + 20 bytes nsParser::ResumeParse(nsIDTD * 0x00000000) line 672 + 11 bytes nsParser::OnDataAvailable(nsParser * const 0x012ced04, nsIURL * 0x012c96d0, nsIInputStream * 0x012a9180, unsigned int 4380) line 868 + 17 bytes nsDocumentBindInfo::OnDataAvailable(nsDocumentBindInfo * const 0x012c9610, nsIURL * 0x012c96d0, nsIInputStream * 0x012a9180, unsigned int 4380) line 1706 + 24 bytes OnDataAvailableProxyEvent::HandleEvent(OnDataAvailableProxyEvent * const 0x01257b00) line 625 StreamListenerProxyEvent::HandlePLEvent(PLEvent * 0x01257b04) line 464 + 12 bytes PL_HandleEvent(PLEvent * 0x01257b04) line 395 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x011baa30) line 357 + 9 bytes _md_EventReceiverProc(void * 0x01a702b0, unsigned int 49215, unsigned int 0, long 18590256) line 675 + 9 bytes

This looks like a DUP of bug 1223 - the "with" construct in JS doesn't work. As with previous bugs that can't be resolved until this bug is fixed, I'm not DUPing it, but assigning it to the owner of 1223 (mccabe in this case). He should reassign it to karnaze@netscape.com once the original bug is fixed.

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

Page does not layout, think Bug 1223 which is still open is culprit.

claudius,re-assigning some of Greg's open bugs to you.

Setting this bug and friend (1223) to m5. Yes, I hope to get to it rsn.

Whoops, actually changing the setting...

These bugs seem to be different aspects of 1223. Shaver has graciously taken 1223; reassigning these to him. (thanks, Mike)

moving to m6

1223 is fixed, so this is back to you, Chris.

Fixed with recent checkins.

VERIFIED Fixed for WinNT builds 1999051309