Closed
Bug 97213
Opened 23 years ago
Closed 13 years ago
cannot run the test case from mfcEmbed.
Categories
(Core Graveyard :: Embedding: APIs, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
mozilla1.1beta
People
(Reporter: dsirnapalli, Unassigned)
Details
(Keywords: embed, topembed-)
Attachments
(1 file)
|
343 bytes,
text/html
|
Details |
I attached the test case. In this test case i am trying to open a window and close it after some time. when i run this test case in mfcEmbed i am not able to reach the alert statment. this works fine in mozilla(i am able to reach the alert statement).
|
Reporter | |
Comment 1•23 years ago
|
||
|
||
Comment 2•23 years ago
|
||
Here's the html src of the test case:
[Note that i modfd. original test case by adding another alert() in fun()]
<html>
<head>
<script type="text/javascript">
var win;
function fun()
{
alert("Closing Window");
win.close();
}
</script>
</head>
<body>
<script type="text/javascript">
win = window.open("http://www.yahoo.com");
if (win)
{
win.onload = setTimeout("fun();", 9000);
}
alert("new window opened and closed");
</script>
</body>
</html>
In MfcEmbed we never reach the |"new window opened and closed"| alert at all.
However, the onLoad() handler gets set properly since i see the |"Closing
Window"| alert in fun().
In 6.1 i see both the alerts.
It looks like it's something to do with the way we're doing a URL load in
embedding. In 6.1 i see the |"new window opened and closed"| alert right away
even *before* the URL load happens.
However, in MfcEmbed we seem to be doing the URL load first and then the
OnLoad() handler setting code takes place, but, i never see the alert()
following that.Status: NEW → ASSIGNED
|
||
Updated•23 years ago
|
QA Contact: mdunn → dsirnapalli
|
||
Comment 3•23 years ago
|
||
It sounds like this could be related to (or a dup of) bug #88229
|
|
||
Comment 4•23 years ago
|
||
you might want to try applying the (quick and dirty) patch for mfcEmbed which is attached to bug #88229 and see if it fixes the problem... if so, then when danm lands the *real* fix, everything should be ok... -- rick
|
|
||
Comment 5•23 years ago
|
||
->0.9.6 since bug #88229 on which this depends is set to that
Target Milestone: --- → mozilla0.9.6
|
|
||
Comment 6•23 years ago
|
||
->0.9.7 since the dependency is moved to that milestone
|
||
Comment 7•23 years ago
|
||
0.9.6 is out the door.
|
|
||
Updated•23 years ago
|
Target Milestone: mozilla0.9.6 → mozilla0.9.8
|
|
||
Comment 8•23 years ago
|
||
Looks like this is not related to bug #88229 - the test case still fails despite #88229 being fixed. It seems to be something else....
|
|
||
Comment 9•23 years ago
|
||
Need to talk to rick more about bug #88229 and see how it relates to this one. Hoping to get this into 0.9.9
Target Milestone: mozilla0.9.8 → mozilla0.9.9
|
||
Updated•22 years ago
|
|
|
||
Comment 11•22 years ago
|
||
Moving out of 1.0 per Choffman's call...
Target Milestone: mozilla1.0 → mozilla1.1beta
|
|
||
Comment 12•22 years ago
|
||
This is not directly related to MfcEmbed ->rpotts Rick : Please reassign if you're not the correct owner...thanks
Assignee: chak → rpotts
Status: ASSIGNED → NEW
|
||
Comment 13•22 years ago
|
||
Bug cleaners at your service! This testcase now works in MFCEmbed 1-8-2003 nightly build. Can someone confirm and close if appropriate.
|
|
||
Comment 14•21 years ago
|
||
This is still working in MFCEmbed using the 12/30/2003 nightly source. Please close this bug.
|
||
Updated•15 years ago
|
Assignee: rpotts → nobody
QA Contact: dsirnapalli → apis
|
||
Comment 15•13 years ago
|
||
Mass marking all MFCEmbed bugs as wontfix, since bug 377410 removed it. If this bug was erroneously included (or say equally applies to winEmbed), please reopen & accept my apologies. Filter bugspam on mfcEmbedwontfix.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
|
||
Updated•5 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•