I can't seem to reload the parent page from within an iframe even though the domain for my iframe and the parent page appear to be the same. The IFRAME was created dynamically, rather than in the HTML page source, so could that be the problem?
The iframe I'm working with is here http://www.avaline.com/ R3000_3 once you log in.
You may use user:test2#gmail.com
pass: test03
Once logged in, hit the "order sample" button, and then hit "here" where it says "Your Third Party Shipper Numbers (To enter one, click here.)".
I tried using javascript statements window.top.location.reload(),window.parent.location.reload(),window.parent.location.href=window.parent.location.href but none of those worked in FF 3.6 so I didn't move on to the other browsers although I am shooting for a cross-browser solution.
I put the one-line javascript statements inside setTimeout("statement",2000) so people could read the content of the iframe before the redirect happens, but that shouldn't affect the execution of the statements...
I wish I could test and debug the statements with the Firebug console from within the Iframe.
Your script tag is:
<script type="test/javascript">
That might be the problem :-)
If changing that to "text/javascript" doesn't fix the issue, try changing the query string slightly:
window.top.location.search = window.top.location.search + '&dc=' + (new Date).getTime();
Related
I have a page where I modded an app to prepopulate a number of fields. I would like to automatically have the 'submit' button be pressed/submitted when the page loads. I have tried things like:
<script type="text/javascript">
function autoclick() {
document.getElementById('buttonid').click();
}
</script>
with
<body onload="autoclick()">
But it does not work.
Any advice would be greatly appreciated!
Thanks
(It is the iframe on this site: http://abraxas.pw)
I see that your iframe is in the same domain and hence it will possible for you as the cross-domain security may not apply.
Give your iframe an id. And then:
document.getElementById('iframeName').contentWindow.document.getElementById("buttonid").click()
More info here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#Scripting
Make sure that the DOM is fully loaded before you fire your Javascript. Wrap this code into body load or iframe load.
Update:
If the iframe is in the same domain and is in your control, you don't need to do all this. Just fire the click from domloaded of jQuery, or place your code at the end (just before body ends). It will work.
Seeing your code, you have defined the function in the head and are calling it at body load. Place the function and the call at the end of the body.
You cannot do it in iframe for security reasons: http://pipwerks.com/2008/11/30/iframes-and-cross-domain-security-part-2/
Content coming from different domain in iframe can't be controlled in your page using javascript.
Browser treats iframe as a different window so you've no access over it. it's something like trying to access content of different window open in your browser from your own window(which is obviously not possible)
Using the latest version of Chrome on Mac OS 10.7.
I assume it is some clever javascript that is enabling the folks at this webpage:
http://www.chairworks.com/
...to close my (the parent) page which opened their (chairworks.com) page in the first place.
I did not open them with javascript, but with an <a> tag with the target="_blank" attribute.
If I disable javascript, then the behavior stops.
www.chairworks.com
I would expect the page at chairworks.com/ to simply open in another tab/window... but what I find is that as soon as the new browser tab opens, it closes, and then my page (the parent tab/window) gets redirected to the chairworks.com page.
Kinda rude.
Can someone point me to what code enables them to do that? And how do I prevent it? (Assuming I want a link to behave as expected, such as in my demo page.)
I believe the proper thing to do is set corresponding link type attribute so the browser doesn't provide the target window with and opener reference.
Link
You can read more about link types here: https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types
This is the script they are using:
setTimeout('redirect_page()',0);
function redirect_page(){if (window.opener) { window.opener.location.href = '/home.html'; window.close(); } else { location.href = '/home.html'; }}
As to how to circumvent it (just an idea):
Create your own blank page, with it's source set to about:blank. When it loads (or after a time-out) you could write some code to that window that will then open the offending link.
Then the offending link just closes your buffer-page. F*ck 'm!! Power to the user!
Edit: looks like you could also name your page home.html hehe, but that is not such a workable solution..
Final Edit: SIMPLE LOGIC people...
www.chairworks.com
works for everyone, no javascript needed.
See this working jsfiddle example.
As #GitaarLAB explained, the targeted website is using the window.opener property to get access to your page. Using some Javascript yourself, and an about:blank page in the middle, can help you cut their access to your page. It would be like:
http://www.chairworks.com/
Some notes:
I'm leaving the href property there for users without JS enabled (guess what! the targeted website won't have JS neither! ;), or the web crawlers like search engines' (only those who don't care about JS stuff, though)
Before redirecting to the targeted website, you cut the back-link by resetting the window.opener attribute of the new window.
And after opening the targeted website, there's a return false; to prevent the normal the browser to use the href and target attributes.
A site that links to mine keeps my site in a frame, so I added the following JavaScript to my page:
if (window.top.location != window.location) {
window.top.location = window.location
}
Now if I get to my site via the offending site, my site successfully breaks out of the frame. But the back button breaks! The back button sends the user to the framed version of my site, which immediately breaks out again, returning him to where he was trying to leave! Is there a simple way to fix this?
window.top.location.replace(window.location);
The replace method is specifically for this purpose. It replaces the current item in the history state with the new destination so that the back button won't go through the destination you don't want.
jfriend00's answer is indeed correct. Using the window.location.replace method will work without affecting the back button.
However, I'd just like to note that whenever you want to stop a page from being framed, you should do more than just that! There are a couple methods of preventing a simple script like that from breaking out of the frame, which work in many modern browsers. Perhaps you can disable the page, display a message with a link to the full page, something like that. You could also use the X-Frame-Options response header that tells the browser not to display the page in a frame. If you don't take some of these measures, your site could be clickjacked.
Another solution is to open your site in a new window leaving a friendly message in the iframed site:
if (parent.frames.length)
{ window.open("mySite.htm", "MySite");
location.href= "framedMessage.htm";
}
Where framedMessage.htm contains some friendly/warning message.
There is a webpage i am making a greasmonkey script for. This page has several iframes. I have found out that they are the problem, however i do not know how to solve the issue.
At first my script creates a small div box with the button. By pressing a button script analyzes webpage contents and calls alert on certain conditions.
Javascript console in Firefox already shouts to me that access was denied for document because my script is using document.getElementByID to find the top document's body, where the div box is being appended to.
This is easily avoidable problem as then script fails and gets stuck in iframes, yet it still continues on the main page as it does give the access to document.
The problem araises when i try to use alert in my function. Seems like iframes take over my script and kills it with the Permission denied to access property 'alert'.
How do i tell browser/script or whatever, that i only want my script to run on main document and i do not want to be bothered by iframes?I installed NO-script addon, allowed the primary domain and blocked the secondary domain (that loads inside iframes) and all the alert messages go normal. But, i can't ask my users to install noscript enable/disable specific domains and my script should be working fine. I need to find solution which would work with all the iframes enabled.
Hope it didn't sound confusing.
Thank you for any help.
RE:
How do i tell browser/script or whatever, that i only want my script to run on main document and i do not want to be bothered by iframes?I installed NO-script addon, allowed the primary domain and blocked the secondary domain (that loads inside iframes) and all the alert messages go normal.
First, adjust your include and exclude directives to ignore the iframes as much as possible. EG:
// #include http://example.com/normal/*
// #include http://example.com/extra/*
// #exclude http://example.com/extra/in_iframe/*
Next, add these 2 lines as the first lines of code after the Metadata Block:
if (window.top != window.self) //-- Don't run on frames or iframes
return;
That will stop the GM script from running on iframes.
This is a very urgent problem and I'd be forever indebted to anyone who can lend some insight.
I'm going to be deploying a widget (called the "ISM") to a third-party site. That site uses the document.domain JavaScript property to relax cross-domain restrictions (e.g., setting document.domain in "a.example.com" and "b.example.com" to both "example.com" so they can access each other's DOMs).
This causes problems with my script in Internet Explorer due to the way that I construct an <iframe> that is used to display my widget's HTML content. In Internet Explorer, using document.domain on a page, and then creating an <iframe> with JavaScript, will cause you to be immediately "locked out" of the <iframe> - i.e., you can create it, but it's not created in the correct document.domain, so you're not able to access its DOM due to security restrictions. This isn't a problem in any other browser.
To see what I'm talking about, load this page in IE:
http://troy.onespot.com/static/3263/stage1.html
You should see a JavaScript error: "Access is denied."
To get around this, I'm setting the dynamically created <iframe>'s "src" attribute to load a static HTML file that's hosted in the same domain (different subdomain), and setting its document.domain property to the appropriate value:
http://troy.onespot.com/static/3263/stage2.html
That gets around the security issue, and lets me write the document I originally wanted to write to the <iframe>:
http://troy.onespot.com/static/3263/stage3.html
With that document in place, my widget does some polling to our server to get some HTML content that I want to insert into another <iframe>, which will be visible to visitors of the parent page. I've roughly simulated that here (using static content, not actually contacting our server):
http://troy.onespot.com/static/3263/stage4.html
Here comes the problem. When I get that HTML content and insert it into the second <iframe>, I now face an unusual issue with a broken "Back" button. This happens in Firefox 3.0 and all version of IE (possibly other browsers), though it does not happen in some browsers I've tested (Firefox 3.5, Safari, Chrome). See this page:
http://troy.onespot.com/static/3263/stage5.html
If you click the "Google" link, all seems fine. But, when navigating back to the previous page (that has the latter test script), another JavaScript error is introduced: "Permission denied." This does not terminate the script, and does not appear to have any ill effects, other than the fact that I assume it's connected to the broken "Back" button functionality, which is a very big problem - the one I'm desperately trying to solve. I'm at a loss to debug this error since its call stack starts and stops in the jQuery script.
You can also encounter this error - with more serious symptoms - by going to the last link above (stage5.html - clear your browser cache first). Click the "Stage 5 (Again)" link, then, after that page has loaded, click the "Back" button.
The "Back" button is completely broken! You can't go anywhere except to another URL.
This is the problem that I need to solve as soon as possible. Any insights or help would be extremely appreciated!
I can't deviate from this method too much, so outside-the-box suggestions are definitely welcome, but I may not be able to use them due to the constraints of the widget's specifications. I would prefer to understand why the "Back" button is breaking and how to fix it, along with the "Permission denied" error related to jQuery.
It's really hard to try out fixes for this because of the multiple domains. One thing I've heard is that IE treats a blank src or "about:blank" as a different domain, but it treats 'javascript:""' as the same domain. Have you experimented with changing stage one to set the iframe src to things like:
iframe.src = 'javascript:""'
Or:
iframe.src = 'javascript:parent.getFrameHTML()'
Part of the problem seems to be that IE (at least IE 7) adds two entries to the history named "Domain" when I click on the "Stage 5 Again" link. When you use the little drop-down arrow next to the Back button you'll see the history of pages allowing you to step back more than one step. I see the previous two entries are listed as "Domain" and clicking either of those brings me to the same page. The fourth spot (after Current Page, Domain, Domain) is the correct "ISM Back Button" link to the original stage5.html page.
So the problem isn't exactly that the back button doesn't work, but just that the entries in the history are added and so the back button takes you to the wrong place. I don't have an answer as to why those "Domain" entries are being added to the history, but hopefully this helps point you in a useful direction.
Good luck!