cannot run the test case from mfcEmbed.




Embedding: APIs
17 years ago
7 years ago


(Reporter: dsirnapalli, Unassigned)


({embed, topembed-})

Windows NT
embed, topembed-

Firefox Tracking Flags

(Not tracked)



(1 attachment)



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).

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()]


<script type="text/javascript">
var win;

function fun()
  alert("Closing Window");


<script type="text/javascript">
win ="");
if (win)
  win.onload = setTimeout("fun();", 9000);

alert("new window opened and closed");



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.


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.


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
Target Milestone: mozilla0.9.9 → mozilla1.0


16 years ago
Keywords: topembed


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


Rick : Please reassign if you're not the correct owner...thanks
Assignee: chak → rpotts

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.
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.