212706 - JavaScript iFrame couldn't fire when hyperlink, or <a href="filename"> is clicked.

Status: VERIFIED INVALID

(SeaMonkey :: General, defect)

Description

[Zook Valem]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030704
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030704

The javascript for iframe that was executed as result of an onclick event to the
hyperlink, or <a href="filename"> had failed to fire as it should have. 
Internet Explorer does not suffer from this problem.  

Reproducible: Always

Steps to Reproduce:
1. Go to the 1st testcase in this bug report.
2. Observe the reaction of the iFrame with the clicking of each of the 3 hyperlinks.
3. Do this on both Mozilla and Internet Explorer at a different time.



Actual Results:  
IFrame is not responding when the hyperlink include a link to a file or URL. 
But IFrame respond when the hyperlink is not pointed to a file or URL.

Expected Results:  
IFrame should have fire or work as it does in Internet Explorer.

The 2nd testcase showed that iframe work only when the alert() event is in use.
 Not an ideal method for the production website but it show that something is
not working right without the alert() event.

Comment 1

[Zook Valem]

I do not know if it is a javascript problem or an iframe problem, so I left the
component setting to Javascript Engine.  Also, I don't know which javascript
category does the 'location.href' fit into, so left the component setting to
Javascript Engine.  Feel free to correct the setting as you see fit.

Comment 2

[Boris Zbarsky [:bzbarsky]]

> 1. Go to the 1st testcase in this bug report.

There are no testcases on this bug report.  No first one, in particular.

Comment 3

[Zook Valem]

Ah!!!  I thougth I just did.  I forgot about that!!!  I will do it tonight when
I get home from work.  Sorry! Thanks for letting me know... Glad to have you on
board.  :-)

Comment 4

[Phil Schwartau]

I don't think this is going to be an Engine issue; reassigning
to Browser-General for now until we get more info -

Comment 5

[Zook Valem]

Attachment: Testcase #1 (Source Code)

Comment 6

[Zook Valem]

Attachment: Testcase #1

Comment 7

[Zook Valem]

Attachment: Testcase #2 (Source Code)

Comment 8

[Zook Valem]

Attachment: Testcase #2

Comment 9

[Boris Zbarsky [:bzbarsky]]

Um... You need to return false from those click handlers, no?  Otherwise the
link will be triggered, as it should be....

Comment 10

[Zook Valem]

Got it!  All testcases are now attached and ready to go...  Had to do it at home
because the testcases are on my laptop there.

Could not find any existing bug for IFrame in Bugzilla, so I created one...  As
for this bug, not sure what the problem is but it look like the handle for
IFrame has not been used or had been overrided by something from somewhere in
the Mozilla coding.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Again, you click the link.  The click handler twiddles the iframe.  Then the
link itself triggers and takes you to a different page altogether.

This is correct behavior, since you don't cancel the click event in your click
handler.

Comment 12

[Zook Valem]

Tried the 'return false;' in the onclick attribute of all of the three '<a
href="<<whatever>>">' and it only succeed in preventing the '<a
href="<<whatever>>">' from working and it made the iframe work.  Not an ideal
solution for the 'Test #1' link if you want to download something. 

Also tried the other way around by using 'return false;' in the FR(parameter1)
function without the 'return false' in the onclick attribute and it does pretty
much the same thing.

The only thing I had observed is that iframe is being act on before the
'<<filename>>' in the hyperlink get executed...

I tried the focus() as when I got the idea from the alert() function that woke
up the iframe and no such luck with that.  I'm pretty sure that something is the
problem with iframe.

Comment 13

[Zook Valem]

Aww!  Mid-Air collision.  Yea, I do noticed as stated from Comment #11 by Boris
that iframe is triggered before the link itself get triggered.

Comment 14

[Boris Zbarsky [:bzbarsky]]

OK, so the only problem then is with case 1.  Here is the sequence of events in
case 1:

1)  iframe load starts
2)  main page load starts, iframe load cancelled since page is probably about to
    go away
3)  main page load gives helper app dialog; page does not go away.

I see no reasonable way to prevent the iframe load being cancelled by the main
page starting the load sequence in step 2, nor do I think there should be one,
particularly.

Comment 15

[Zook Valem]

Perhap a delay to the execution of the main page until things get done.  No need
to cancel execution of the main page as what the javascript was already written
to.  I have no desire to cancel the execution, just get javascript to do what it
need to do.

Comment 16

[Boris Zbarsky [:bzbarsky]]

What is "get done?"  The user clicked on a link; we need to follow it.

Comment 17

[Zook Valem]

What is 'get done' is the onclick attribute.  The onclick attribute then go to
the JavaScript function where everything within the function had to be run and
be given the opportunity finish before the '<a href='<<filename>>'>' link get
executed.  The javascript function just got interrupted before it ever finish
the work as we noticed.  What you're saying here is that it is okay for iframe
not to work.  This is wrong, this is not how the onclick work and this is not
how the javascript work.  Javascript have the higher authority than the HTML '<a
href='<<filename>>'>' links or you're letting the purpose of JavaScript be
defeated.  The onclick attribute also have a higher authority than the '<a
href='<<filename>>'>' as well.  The IE did this job correctly, so do some
non-Gecko browsers.  The IE-only websites had to stop and it stop right here.

It seem nobody is getting the picture here.  So, I'm creating a new testcase to
point this out.  This testcase showed that there's nothing in the '<a href=''>'
but letting the onclick attribute to do the job.  As you can see in this new
testcase, Iframe is not getting the job done and it came first before the
'location.href' for the file download.  Mozilla just skipped the iframe and go
directly to the file download which is not suppose to happen.

The alert() function showed that the iframe work.  The alert() function is part
of javascript and either the alert() or the javascript had the higher authority
than the HTML '<a href='<<filename>>'>'.  So, something is wrong here.  Check
out the testcase.

Comment 18

[Zook Valem]

Attachment: Testcase #3 (Source Code)

Comment 19

[Zook Valem]

Attachment: Testcase #3

Comment 20

[Zook Valem]

Attachment: Testcase #3 (Source Code)

Darn!  Forgot to comment out the alert() function...  So, here's a fresh
copy...

Comment 21

[Zook Valem]

Attachment: Testcase #3

And here's another one...

Comment 22

[Boris Zbarsky [:bzbarsky]]

> The javascript function just got interrupted before it ever finish
> the work as we noticed.

Wrong.  The function just tells the iframe to start a load.  This completes
successfully.  The load itself happens asynchronously after that.

> Javascript have the higher authority

It does.  It runs before the link gets triggered.  It has a chance to cancel the
link being triggered.  BUT YOUR SCRIPT DOES NOT DO THAT.  That is all.

Your new testcase shows nothing new.  Again, the sequence of events is:

1)  Onclick handler runs.  This starts the iframe load and has a chance to
    prevent the href from being followed.
2)  The iframe load happens asynchronously (in IE the load happens syncronously;
    this is a key difference between document loads in general in Mozilla and IE
    and will not be getting changed in Mozilla).
3)  If the href action was not cancelled by the script, the href is followed;
    this cancels all pending loads and follows the href.

The key issue here is #2, of course -- if the iframe load had to complete before
the event handler returned, there would be no issue here.  But that is simply
not the way document loading works in mozilla; if you want something to execute
right after the iframe loads, just hook it up as an onload listener on the
iframe; then you will not be relying on synchronous document loading behavior.

Comment 23

[Jon Henry]

I'm not an expert on JavaScript implementation, just trying to clear
Browser-General of bugs. Is it agreed that this feature is functioning as it
should? If so, we might as well mark it invalid, or at least move it to DOM: Events.

Comment 24

[Boris Zbarsky [:bzbarsky]]

Yeah, this is invalid.

Comment 25

[Zook Valem]

Yea, go ahead and mark it as invalid.  Saw the workaround to this problem on the
Internet, it said that all you need is to use the JavaScript Timer to set a
delay time and it work.  Sort of like time interval.  In due time, people will
become more educated on how to use JavaScript to control the response time of
the hyperlink.