cannot run the test case from mfcEmbed.

RESOLVED WONTFIX

Status

()

Core
Embedding: APIs
RESOLVED WONTFIX
17 years ago
7 years ago

People

(Reporter: dsirnapalli, Unassigned)

Tracking

({embed, topembed-})

Trunk
mozilla1.1beta
x86
Windows NT
embed, topembed-
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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
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

Comment 10

16 years ago
->1.0
Target Milestone: mozilla0.9.9 → mozilla1.0

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. 
Assignee: rpotts → nobody
QA Contact: dsirnapalli → apis
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.