Closed Bug 3487 Opened 26 years ago Closed 25 years ago

Frames history problem

Categories

(SeaMonkey :: UI Design, defect, P2)

x86
Windows 98

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: brianbryce, Assigned: radha)

References

()

Details

Build - Nightly - ????-9901052:49- 3-5-99 I guess it is 5.0a1-9901052:49 my system Dell win 98 P II 350 128 ram connected to network useing standard 10/100 Netgear car (I forget the number but it is the only one they make) Funny problem when useing back bution in frames it all the frames go back not just the most recently called frame. This might not be an error but it mgiht sure screw up the web.... does it consitently Also printer error, on print crash (http printing not ready?): www.mozilla.org VIEWER.EXE caused fault #c0000005 in RAPTORHTML.DLL at address 018f:005de20e To date, CrashGuard has recorded 4 fatal error(s) in this program. Reported By: CrashGuard v3.03 Report Date: 3/6/99 9:17:34 PM WindowTitle: viewer Last Message: MSG("mozilla.org - Raptor", WM_COMMAND, MenuItem: "&File/Print", 00000000) Program: E:\PROGRAM\NETSCAPE\NIGHTLY\TEST\BIN\VIEWER.EXE (03/05/99 07:52 - 60928) Registers: EAX=00000000 CS=018f EIP=005de20e EFLGS=00010246 EBX=00b3cde0 SS=0197 ESP=0093e9c4 EBP=0093eae8 ECX=0093ead8 DS=0197 ESI=00000000 FS=1bc7 EDX=00000000 ES=0197 EDI=80000000 GS=0000 Bytes at CS:EIP: 8b 08 ff 51 08 39 73 18 74 4e 8b 45 08 8d 55 08 Stack dump: 00000000 00000001 00b3cde0 00000000 00000000 0000003f 00000000 00000032 bff7b9b6 817e7248 00000032 7800136c 78034108 0093eab4 00000033 017dc560 while printing www.cnet.com VIEWER.EXE caused fault #c0000005 in RAPTORHTML.DLL at address 018f:00600b51 To date, CrashGuard has recorded 2 fatal error(s) in this program. Reported By: CrashGuard v3.03 Report Date: 3/6/99 8:49:59 PM WindowTitle: viewer Last Message: MSG("CNET.com - Welcome to CNET! - Raptor", WM_COMMAND, MenuItem: "&File/Print", 00000000) Program: E:\PROGRAM\NETSCAPE\NIGHTLY\TEST\BIN\VIEWER.EXE (03/05/99 07:52 - 60928) Registers: EAX=0163e8c4 CS=018f EIP=00600b51 EFLGS=00010246 EBX=00001cc4 SS=0197 ESP=0093bce8 EBP=0093bcf4 ECX=00000000 DS=0197 ESI=0093bd78 FS=562f EDX=0093bce0 ES=0197 EDI=018063f0 GS=0000 Bytes at CS:EIP: 8b 01 ff 50 0c 8b d8 5f 8b c3 5e 5b 5d c2 04 00 Stack dump: 0093bfdc 018063f0 0093c210 0093bd50 005ffe24 0163e8c4 018063f4 018063f0 0093be64 0093bd78 00001cc4 40000000 00000000 00000001 0000056e 00000000
Assignee: rickg → karnaze
Please take a look at the frame problem cited here.
Severity: normal → major
Component: Viewer App → HTMLFrames
Priority: P2 → P1
QA Contact: 3853 → 4082
Target Milestone: M3
Setting component to HTMLFrames. glynn, could you please try a print with frames and let us know results with latest build.
QA Contact: 4082 → 3819
Printer issue: Prints with March 10 build, win98, with Viewer, printout is messed up ut no crash. Filing bug for print specific issue. "Frame" issue: seems like a history problem. I don't know if frames history is enabled yet. QA assign to paulmac for history/cache question.
Just a comment on the original bug... Here is waht happens in detail... (I don't know if it still works this way but I suspect it does...): You start on your "home" site say - www.netscape.com from there you go to a page with frames say the code is: <FRAMESET COLS="20%,80%" border=0 frameborder=no framespacing=0 marginwidth=0 marginheight=0> <FRAMESET ROWS="10%,65%,25%" border=0 frameborder=no framespacing=0 marginwidth=0 marginheight=0> <FRAME NAME="home" SRC="bryce.htm" border=0 MARGINHEIGHT=0 MARGINWIDTH=0 SCROLLING=NO NORESIZE> <FRAME NAME="toc" SRC="toc.htm" border=0 MARGINHEIGHT=0 MARGINWIDTH=0 SCROLLING=AUTO NORESIZE> <FRAME NAME="free" SRC="free.htm" border=0 MARGINHEIGHT=0 MARGINWIDTH=0 SCROLLING=NO NORESIZE> </FRAMESET> <FRAMESET ROWS="100%" border=0 frameborder=no framespacing=0 marginwidth=0 marginheight=0> <FRAME NAME="main" SRC="main.htm" border=0 MARGINHEIGHT=0 MARGINWIDTH=0 SCROLLING=AUTO NORESIZE> </FRAMESET> Now the user uses a link in the "toc" frame which calles its page to open in the frame called "main" everything is fine so far.... BUT now the user wishes to go back and by this they want just the frame called "main" to go back to its original document in this case "main.htm" Here is the problem if the back buttion is pushed the document will go back to the document before the frameset page in this case "www.netscape.com" it will NOT just send the "main" section back one page in the history as current versions of Netscape (release)do.
Assignee: karnaze → don
It looks like a separate bug was filed for the printing issue. The remaining history issue needs to be driven by the applications group (even though the layout group surely will need to do some work).
Assignee: don → rpotts
Target Milestone: M3 → M4
Re-assigned to rpotts@netscape.com and changed target milestone to M4. Rick ...?
Component: HTMLFrames → XPApps
Priority: P1 → P2
Downgrade priority to P2 and component to XPApps. Hmmm, what does UE actually want us to do here?
Assignee: rpotts → don
Target Milestone: M4 → M5
Assignee: don → radha
Summary: printer problems and frames malfuntions → Frames history problem
Target Milestone: M5 → M6
Re-assigned to radha; changed summary and target milestone to M6. Radha, figure out what the right thing to do is here ...
Status: NEW → ASSIGNED
Though cnn and mozilla.org seems to load fine these days, a page similar to the text provided here doesn't work. Shall take a look.
Target Milestone: M6 → M7
Won't be here for M6. Moving to M7
*** Bug 5972 has been marked as a duplicate of this bug. ***
*** Bug 6018 has been marked as a duplicate of this bug. ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Feature checked in.Please verify.
Status: RESOLVED → VERIFIED
verified fixed with 6/15 builds
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.