1015 bytes, text/plain
1015 bytes, text/html
1.03 KB, text/plain
1.03 KB, text/html
786 bytes, text/plain
786 bytes, text/html
> 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
QA Contact: pschwartau → general
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.
What is "get done?" The user clicked on a link; we need to follow it.
Created attachment 128044 [details] Testcase #3 (Source Code) Darn! Forgot to comment out the alert() function... So, here's a fresh copy...
Attachment #128042 - Attachment is obsolete: true
Created attachment 128045 [details] Testcase #3 And here's another one...
Attachment #128043 - Attachment is obsolete: true
Yeah, this is invalid.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.