crash caused by linked stylesheet on page with frameset

VERIFIED FIXED in M5

Status

()

Core
Layout: HTML Frames
P1
major
VERIFIED FIXED
20 years ago
19 years ago

People

(Reporter: dbaron, Assigned: karnaze (gone))

Tracking

Trunk
x86
Windows 95
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Linked stylesheet is not the problem: crash is caused by the location of a FRAME element in the document, URL)

viewer and xpviewer both crash when loading this page... Norton Utilities
doesn't even let them get to the point where the page starts to display.  If I
tell Norton to "fix the crash," then the pages display with garbage on the
border between the frames, and only a few of the links work.
(Assignee)

Updated

20 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

20 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
(Assignee)

Comment 1

20 years ago
It works on my 11/30 NT debug build using viewer.
Status: RESOLVED → REOPENED
I still get crashes, although I did get it to sucessfully load once.  That one
time was when my home page (which is set to http://www.fas.harvard.edu/~dbaron/
using NGLAYOUT_HOME) was slow to load, and I typed in the above URL before the
home page loaded.  Other than that, the page still crashes.  Telling Norton to
fix the crash locks up the system.  Norton's description of the crash is an
"Access Violation."  I am using the optimized build in
ftp://ftp.mozilla.org/pub/mozilla/nightly/12-02/mozilla-win32.zip (I think
that's the link...it's just from memory.)
Resolution: FIXED → ---
OK... still have crashes here, but if I tell norton to "Fix the program" (or
whatever), it renders the page, put with garbage from other windows on the
frameborder.
Well... I just got it to work fine (this is the 98-12-07 build).  I guess when
it crashes it is the second page that I load.  I have NGLAYOUT_HOME set to
http://www.fas.harvard.edu/~dbaron/, so that loads first, and then I click on
"International Weather Satellite Imagery" from that page (the third link in the
list?), and I get the crash.  But I didn't after I had been looking at other
pages for a while.
(Assignee)

Updated

20 years ago
Assignee: karnaze → rickg
Status: REOPENED → NEW
(Assignee)

Comment 5

20 years ago
http://www.fas.harvard.edu/~dbaron/ now has a problem in the latest debug build.
The following test illustrates what the problem is. The <SCRIPT> .. </SCRIPT> is
erroneously causing a <BODY> to be inserted into the content model, thus causing
the frameset stuff to be ignored. By removing the <SCRIPT>, the <BOY>
is not inserted and the framesets work. Substitute test00.html for a small file
of your own.

It looks like a parser bug.

<HTML>
<HEAD>
<SCRIPT LANGUAGE="JavaScript" TYPE="text/javascript">
</SCRIPT>
</HEAD>
<FRAMESET COLS="30%,70%" BORDERCOLOR="#CC2211">
 <FRAMESET ROWS="40%,60%">
  <FRAME SRC="test00.html" FRAMEBORDER=1>
  <FRAME SRC="test00.html" FRAMEBORDER=1>
 </FRAMESET>
 <FRAME SRC="test00.html" FRAMEBORDER=1>
</FRAMESET>

</HTML>

Updated

20 years ago
Status: NEW → ASSIGNED

Updated

20 years ago
Assignee: rickg → troy
Status: ASSIGNED → NEW

Comment 6

20 years ago
This appears to be a reflow problem. StartLayout() is called when the inner
frameset is closed (and then we freeze). If you prevent this and dump the conten
t model, all appears as it should.

Updated

20 years ago
Assignee: troy → karnaze

Comment 7

20 years ago
This is definitely a frameset problem. I don't know why this is happening, but
here's what is happening:

We're in nsHTMLFramesetFrame::CanResize() and we're stuck in the "for" loop
inside of the "if (aVertical)" if-stmt, because mNumCols is '0' and
mNonBorderChildCount is '65' and so we never exit the loop

Here's the full stack trace:
nsHTMLFrameElement::AddRef(nsHTMLFrameElement * const 0x00fa3970) line 111 + 9
bytes
nsFrame::GetContent(const nsFrame * const 0x00fab890, nsIContent * & 0x00000000)
line 354 + 27 bytes
nsHTMLFramesetFrame::GetNoResize(nsIFrame * 0x00fab890) line 1239
nsHTMLFramesetFrame::CanChildResize(int 1, int 1, int 0, int 0) line 1261 + 12
bytes
nsHTMLFramesetFrame::CanResize(int 1, int 1) line 1216 + 33 bytes
nsHTMLFramesetFrame::CanChildResize(int 1, int 1, int 1, int 1) line 1259 + 16
bytes
nsHTMLFramesetFrame::SetBorderResize(int * 0x00faa1e0, nsHTMLFramesetBorderFrame
* 0x00fae700) line 1272 + 71 bytes
nsHTMLFramesetFrame::Reflow(nsHTMLFramesetFrame * const 0x00faa870,
nsIPresContext & {...}, nsFramesetDrag * 0x00000000, nsHTMLReflowMetrics &
{...}, const nsHTMLReflowState & {...}, unsigned int & 1240316) line 1161
nsHTMLFramesetFrame::Reflow(nsHTMLFramesetFrame * const 0x00faa874,
nsIPresContext & {...}, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState &
{...}, unsigned int & 1240316) line 813
nsInlineReflow::ReflowFrame(int 1, nsHTMLReflowMetrics & {...}, unsigned int &
1240316) line 447
nsInlineReflow::ReflowFrame(nsIFrame * 0x00faa870, int 1, unsigned int &
1240316) line 269 + 20 bytes
nsBaseIBFrame::ReflowInlineFrame(nsBlockReflowState & {...}, nsLineBox *
0x00faa800, nsIFrame * 0x00faa870, int & 1, int & 1) line 2276 + 31 bytes
nsBaseIBFrame::ReflowLine(nsBlockReflowState & {...}, nsLineBox * 0x00faa800,
int & 1) line 1634 + 28 bytes
nsBaseIBFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 1328 + 26 bytes
nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 4868
nsBaseIBFrame::Reflow(nsBaseIBFrame * const 0x00faaca4, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 803 + 25 bytes
nsBlockFrame::Reflow(nsBlockFrame * const 0x00faaca4, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 4501 + 25 bytes
nsAreaFrame::Reflow(nsAreaFrame * const 0x00faaca4, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 508 + 25 bytes
nsContainerFrame::ReflowChild(nsIFrame * 0x00faaca0, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 363 + 28 bytes
RootFrame::Reflow(RootFrame * const 0x00fa9084, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 232
nsContainerFrame::ReflowChild(nsIFrame * 0x00fa9080, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 363 + 28 bytes
ViewportFrame::Reflow(ViewportFrame * const 0x00fa03a4, nsIPresContext & {...},
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0)
line 105
PresShell::InitialReflow(PresShell * const 0x00f9dcf0, int 11580, int 9150) line
719
HTMLContentSink::StartLayout() line 1998
HTMLContentSink::CloseFrameset(HTMLContentSink * const 0x00f5ef30, const
nsIParserNode & {...}) line 1808
CNavDTD::CloseFrameset(const nsIParserNode & {...}) line 2161 + 31 bytes
CNavDTD::CloseContainer(const nsIParserNode & {...}, nsHTMLTag
eHTMLTag_frameset, int 1) line 2289 + 12 bytes
CNavDTD::CloseContainersTo(int 1, nsHTMLTag eHTMLTag_frameset, int 1) line 2326
+ 20 bytes
CNavDTD::CloseContainersTo(nsHTMLTag eHTMLTag_frameset, int 1) line 2347 + 20
bytes
CNavDTD::HandleEndToken(CToken * 0x00f9eb70) line 1044 + 14 bytes
NavDispatchTokenHandler(CToken * 0x00f9eb70, nsIDTD * 0x00f9dae0) line 252 + 12
bytes
CTokenHandler::operator()(CToken * 0x00f9eb70, nsIDTD * 0x00f9dae0) line 80 + 14
bytes
CNavDTD::HandleToken(CNavDTD * const 0x00f9dae0, CToken * 0x00f9eb70, nsIParser
* 0x00f5d0c0) line 577 + 18 bytes
CNavDTD::BuildModel(CNavDTD * const 0x00f9dae0, nsIParser * 0x00f5d0c0,
nsITokenizer * 0x00f9d750, nsITokenObserver * 0x00000000, nsIContentSink *
0x00f5ef30) line 507 + 20 bytes
nsParser::BuildModel() line 727 + 34 bytes
nsParser::ResumeParse(nsIDTD * 0x00000000) line 681 + 11 bytes
nsParser::OnDataAvailable(nsParser * const 0x00f5d0c4, nsIURL * 0x00f20d60,
nsIInputStream * 0x00f24fc0, unsigned int 2613) line 891 + 17 bytes
nsDocumentBindInfo::OnDataAvailable(nsDocumentBindInfo * const 0x00f23030,
nsIURL * 0x00f20d60, nsIInputStream * 0x00f24fc0, unsigned int 2613) line 1716 +
24 bytes
OnDataAvailableProxyEvent::HandleEvent(OnDataAvailableProxyEvent * const
0x00fa1240) line 629
StreamListenerProxyEvent::HandlePLEvent(PLEvent * 0x00fa1244) line 468 + 12
bytes
PL_HandleEvent(PLEvent * 0x00fa1244) line 395 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00ece1f0) line 357 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00570816, unsigned int 49386, unsigned int 0,
long 15524336) line 675 + 9 bytes
USER32! 77e71250()
00ece1f0()
(Assignee)

Comment 8

20 years ago
The simple test case I entered on 1/20 now seems to work and the <body> tag has
been removed. Rick: you must have done something to make this go away.

The original problem as stated on entry 12/07 seems to work for me when I do
exactly what it says. I was using a debug build (mid day 1/25) without the
debugger.

Troy: How are you getting the latest error you report? Are you using a release
build?
Status: NEW → RESOLVED
Last Resolved: 20 years ago20 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I recently started browser-sniffing the CSS on this page.  Therefore you may
need to set NG_REQUEST_VER=5.0 to see the crash.  I am still crashing using the
99-01-26 build.

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

Comment 11

20 years ago
Setting all current Open Critical and Major to M3
I got this to load once in the 99-02-09 build, but then I went back and tested
it in 01-22, and it crashed, and went back to 02-09, and it crashed in that
too.  I'm not sure what's really going on.
The crash here is triggered by the presence of a linked stylesheet in the
document containing the FRAMESET.

I *think* (but I'm not sure) that this stylesheet should apply only to the
noframes content (for browsers that don't support frames) and should not apply
to the contained pages.  I would think that that would be the legacy behavior
(but I didn't check).

cc:ing peterl@netscape.com
(Assignee)

Comment 14

19 years ago
I tried this on the 2/22 NT debug build and had no problems. I set
NG_REQUEST_VER=5.0 and NGLAYOUT_HOME=http://www.fas.harvard.edu/~dbaron/ and
went to "International Weather Satellite Imagery" as the 2nd page.
On 1/26 I could not get it to fail either (see my comments).

Can someone in QA please verify if this is only a problem for a release build?

Updated

19 years ago
QA Contact: 4110
(Assignee)

Updated

19 years ago
Status: REOPENED → RESOLVED
Last Resolved: 20 years ago19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 15

19 years ago
Chris Dreckman verified that viewer doesn't crash on a 3/1 optimized Win95
build.
Status: RESOLVED → VERIFIED
Verified fixed on build of 99-03-02.  (And it did crash using 99-02-25, so the
fix was in the past week.)
Status: VERIFIED → REOPENED
Summary: viewer and xpviewer crash on this page → crash caused by linked stylesheet on page with frameset
I hate to tell you this, but this bug has resurfaced in the build of 1999-03-
05.

If I remove the linked stylesheet from the page containing the frameset, there
is no crash.  If I make the linked stylesheet empty, it still crashes.  So the
crash is caused by the mere presence of the linked stylesheet on the frameset
page.

Updated

19 years ago
Resolution: FIXED → ---

Comment 18

19 years ago
Removing the fixed resolution; this URL still crashes

Updated

19 years ago
Target Milestone: M3 → M4

Comment 19

19 years ago
moving to m4

Comment 20

19 years ago
Isolated the bug:

Open this URL:
http://slip/projects/marvin/bugs/1596_works.html

If you look at the source code, <FRAME SRC="c.html"> is inserted after the first
FRAMESET element 'opening' tag.

Open this URL (in Navigator, Gecko will crash):
http://slip/projects/marvin/bugs/1596_crash.html

If you look at the source code, <FRAME SRC="c.html"> is inserted after the first
FRAMESET element 'closing' tag.

The placement of the <FRAME> element should be legal in either location and
should not cause the application to crash.

Updated

19 years ago
Whiteboard: Linked stylesheet is not the problem: crash is caused by the location of a FRAME element in the document

Updated

19 years ago
Assignee: karnaze → rickg
Status: REOPENED → NEW

Comment 21

19 years ago
Rick, this may be related to work you're doing now. If the crash is still tied
to the presence of an stylesheet (especially an empty one), the the problem is
related to ReconstructDocElementHierarchy and should be transferred to karnaze
or troy.

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED

Comment 22

19 years ago
Fixed by recent improvements to script handling in DTD.
(Assignee)

Comment 23

19 years ago
I hope you really have fixed it. It has had as many lives and deaths as the
proverbial cat. It would work on debug builds but fail on optimized ones.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 24

19 years ago
Verified fixed cross platform in March 22 builds.

Updated

19 years ago
Status: VERIFIED → REOPENED

Comment 25

19 years ago
Broken again in march 23 builds..:-(

Updated

19 years ago
Resolution: FIXED → ---

Comment 26

19 years ago
Greg: This bug also crashed on 3/22 builds - please let me work on this bug as I
am qa contact and have been working on this bug.

Comment 27

19 years ago
chrisd only will verify this when fixed.  Fyi with Mar 22 builds on my machines
it did work properly.  I loaded March 23 builds on same machines it crashed.  I
went back to March 22 builds and it worked.  So chrisd's machine will be the holy
grail to say when this puppy is fixed for sure.

Updated

19 years ago
Assignee: rickg → karnaze
Status: REOPENED → NEW

Comment 28

19 years ago
Chris -- back to you. Now it's dying in frame resize code.

Updated

19 years ago
Target Milestone: M4 → M5

Comment 29

19 years ago
move to m5
(Assignee)

Updated

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

Comment 30

19 years ago
Ok, I know nobody is going to believe me, but I think I have fixed this with my
latest checkin.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 31

19 years ago
Using 4/13 build, verified fixed. URL does not crash.
You need to log in before you can comment on or make changes to this bug.