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.