1322 - We aren't honoring MARGINWIDTH attribute on this frameset document

Status: VERIFIED FIXED

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

Description

[Angus Davis]

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

Comment 1

[karnaze (gone)]

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

Comment 2

[vidur (gone)]

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 [e-mail] once the original bug is fixed.

Comment 3

[leger]

Setting all current Open/Normal to M4.

Comment 4

[Paul MacQuiddy]

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

Comment 5

[glynn]

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

Comment 6

[sujay]

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

Comment 7

[Mike McCabe]

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

Comment 8

[Mike McCabe]

Whoops, actually changing the setting...

Comment 9

[Mike McCabe]

These bugs seem to be different aspects of 1223.  Shaver has graciously taken
1223; reassigning these to him.

(thanks, Mike)

Comment 10

[chris hofmann]

moving to m6

Comment 11

[shaver-do-not-use-this-account]

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

Comment 12

[karnaze (gone)]

Fixed with recent checkins.

Comment 13

[Claudius Gayle]

VERIFIED Fixed for WinNT builds 1999051309