Closed Bug 212706 Opened 22 years ago Closed 21 years ago

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

Categories

(SeaMonkey :: General, defect)

x86
Windows 2000
defect
Not set
major

Tracking

(Not tracked)

VERIFIED INVALID

People

(Reporter: ZookQValem, Unassigned)

Details

Attachments

(6 files, 2 obsolete files)

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.
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.
> 1. Go to the 1st testcase in this bug report. There are no testcases on this bug report. No first one, in particular.
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. :-)
I don't think this is going to be an Engine issue; reassigning to Browser-General for now until we get more info -
Assignee: rogerl → general
Component: JavaScript Engine → Browser-General
QA Contact: pschwartau → general
Attached file Testcase #1
Attached file Testcase #2
Um... You need to return false from those click handlers, no? Otherwise the link will be triggered, as it should be....
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.
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.
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.
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.
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.
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.
What is "get done?" The user clicked on a link; we need to follow it.
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.
Attached file Testcase #3 (Source Code) (obsolete) —
Attached file Testcase #3 (obsolete) —
Darn! Forgot to comment out the alert() function... So, here's a fresh copy...
Attachment #128042 - Attachment is obsolete: true
Attached file Testcase #3
And here's another one...
Attachment #128043 - Attachment is obsolete: true
> 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.
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.
Yeah, this is invalid.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
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.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: