We aren't honoring MARGINWIDTH attribute on this frameset document

VERIFIED FIXED in M6

Status

()

Core
Layout: HTML Frames
P2
normal
VERIFIED FIXED
20 years ago
19 years ago

People

(Reporter: Angus Davis, Assigned: karnaze (gone))

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: handed back (bug 1223 fixed), URL)

(Reporter)

Description

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

Updated

20 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

20 years ago
Assignee: karnaze → vidur
Status: ASSIGNED → NEW
(Assignee)

Comment 1

20 years ago
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

Updated

20 years ago
Assignee: vidur → mccabe

Comment 2

20 years ago
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.

Comment 3

20 years ago
Setting all current Open/Normal to M4.

Comment 4

20 years ago
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

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

Comment 6

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

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 7

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

Updated

20 years ago
Target Milestone: M4 → M5

Comment 8

20 years ago
Whoops, actually changing the setting...

Updated

19 years ago
Assignee: mccabe → shaver
Status: ASSIGNED → NEW

Comment 9

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

(thanks, Mike)

Updated

19 years ago
Whiteboard: need status update

Updated

19 years ago
Whiteboard: need status update → still waiting on bug 1223? - 5/03

Updated

19 years ago
Target Milestone: M5 → M6

Comment 10

19 years ago
moving to m6

Updated

19 years ago
Status: NEW → ASSIGNED
1223 is fixed, so this is back to you, Chris.

Updated

19 years ago
Assignee: shaver → karnaze
Status: ASSIGNED → NEW
Whiteboard: still waiting on bug 1223? - 5/03 → handed back (bug 1223 fixed)
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 12

19 years ago
Fixed with recent checkins.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 13

19 years ago
VERIFIED Fixed for WinNT builds 1999051309
You need to log in before you can comment on or make changes to this bug.