Status
()
People
(Reporter: dsirnapalli, Unassigned)
Tracking
({embed, topembed-})
Firefox Tracking Flags
(Not tracked)
Details
Attachments
(1 attachment)
|
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•17 years ago
|
||
Created attachment 47284 [details]
test case
|
||
Comment 2•17 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•17 years ago
|
||
QA Contact: mdunn → dsirnapalli
|
||
Comment 3•17 years ago
|
||
It sounds like this could be related to (or a dup of) bug #88229
|
|
||
Comment 4•17 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•17 years ago
|
||
->0.9.6 since bug #88229 on which this depends is set to that
Target Milestone: --- → mozilla0.9.6
|
|
||
Comment 6•17 years ago
|
||
->0.9.7 since the dependency is moved to that milestone
|
||
Comment 7•17 years ago
|
||
0.9.6 is out the door.
|
|
||
Updated•17 years ago
|
||
Target Milestone: mozilla0.9.6 → mozilla0.9.8
|
|
||
Comment 8•17 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•17 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•16 years ago
|
||
Keywords: topembed
|
||
Updated•16 years ago
|
||
Keywords: topembed → embed, topembed-
|
|
||
Comment 11•16 years ago
|
||
Moving out of 1.0 per Choffman's call...
Target Milestone: mozilla1.0 → mozilla1.1beta
|
|
||
Comment 12•16 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•16 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•15 years ago
|
||
This is still working in MFCEmbed using the 12/30/2003 nightly source. Please close this bug.
|
||
Updated•9 years ago
|
||
Assignee: rpotts → nobody
QA Contact: dsirnapalli → apis
|
||
Comment 15•7 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
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•