Closed Bug 1596 Opened 26 years ago Closed 26 years ago

crash caused by linked stylesheet on page with frameset

Categories

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

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Platform:
x86
Windows 95
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: dbaron, Assigned: karnaze)

References

(
URL
)

Details

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

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.
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
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: karnaze → rickg
Status: REOPENED → NEW
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>
Status: NEW → ASSIGNED
Assignee: rickg → troy
Status: ASSIGNED → NEW
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.
Assignee: troy → karnaze
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()
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
Closed: 26 years ago → 26 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. ***
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
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?
QA Contact: 4110
Status: REOPENED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
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.
Resolution: FIXED → ---
Removing the fixed resolution; this URL still crashes
Target Milestone: M3 → M4
moving to m4
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.
Whiteboard: Linked stylesheet is not the problem: crash is caused by the location of a FRAME element in the document
Assignee: karnaze → rickg
Status: REOPENED → NEW
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.
Status: NEW → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
Fixed by recent improvements to script handling in DTD.
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.
Status: RESOLVED → VERIFIED
Verified fixed cross platform in March 22 builds.
Status: VERIFIED → REOPENED
Broken again in march 23 builds..:-(
Resolution: FIXED → ---
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.
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.
Assignee: rickg → karnaze
Status: REOPENED → NEW
Chris -- back to you. Now it's dying in frame resize code.
Target Milestone: M4 → M5
move to m5
Status: NEW → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
Ok, I know nobody is going to believe me, but I think I have fixed this with my latest checkin.
Status: RESOLVED → VERIFIED
Using 4/13 build, verified fixed. URL does not crash.
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.