Closed Bug 2507 Opened 26 years ago Closed 26 years ago

[CRASH] loading page - page fails to render at all

Categories

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

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

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: andreww, Assigned: vidur)

References

(
URL
)

Details

Not sure why this is happening - the site seems to just be a simple frameset page... This is build 091999
Setting all current Open/Normal to M4.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
It works on my 2/27 NT debug build. QA - please verify if it is an optimized build problem.
Status: RESOLVED → REOPENED
QA Contact: 4082
Hardware: PC → All
Summary: page fails to render at all → crash loading page - page fails to render at all
Resolution: WORKSFORME → ---
Reopened - with March 22 builds, optimized, apprunner or viewer Added myself as qa contact; crashes cross platform Windows - invalid page fault in module JS3250.DLL, Mac hangs or drops into macsbug with unmapped mem exception at nsmem alloc leading to PR_Free, Linux just quits itself.
Summary: crash loading page - page fails to render at all → [CRASH] loading page - page fails to render at all
Chris, re-assigning some of Greg's old bugs to you.
Assignee: karnaze → vidur
Status: REOPENED → NEW
On a 3/30 WinNT debug build there is strange behavior and I think it may be some javascript going wild. There is an error - JavaScript error: Package java defined twice. The page keeps loading and loading. There are also messages in nsFramesetFrame indicating that the destructor is being call many times. Vidur, I'm not making much progress in finding out what is wrong here. Please take a look. I'm leaving it as M4, but that can be easily changed.
Recent changes to the parser seem to have caused another bug that masks the initial one. The document.written frames (from a SCRIPT tag in the HEAD) are kept in a "misplaced tags" list by the parser and seem to be emitted only *after* the FRAMSET content below the HEAD. This is different from the way it once was i.e. document.written content *before* the FRAMESET content below the HEAD.
Assignee: vidur → rickg
Rick, as per our conversation, I'm reassigning to you. Please send it back after you look at it.
Parser error test case reduced to: <HTML> <HEAD> <SCRIPT> document.write("<FRAMSET ROWS='50,50'>"); document.write(" <FRAME SRC=about:blank>"); document.write(" <FRAME SRC=about:blank>"); document.write("</FRAMESET>"); </SCRIPT> </HEAD> <FRAMESET ROWS = 50,50> <FRAME SRC=about:blank> <FRAME SRC=about:blank> </FRAMESET> <NOFRAMES> <BODY> <BR> </BODY> </NOFRAMES> </HTML>
Target Milestone: M4 → M5
move to m5
move to m5
Target Milestone: M5 → M6
This is fixed in my tree -- but I was blocked from checking it in last weekend. Now there's too much risk. Moving to M6.
Assignee: rickg → vidur
V -- this is fixed now. Please review.
Status: NEW → ASSIGNED
Target Milestone: M6 → M7
Well the original bug was fixed, but there's something drastically wrong with this page - it never completes loading and brings my machine to a halt. Saving investigation for M7.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
Ahh, don't you love it when bugs fix themselves. Seems to work in the 6/14/99 build.
Mystery fix! Marking verified.
Status: RESOLVED → VERIFIED
*** Bug 54088 has been marked as a duplicate of this bug. ***
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.