Question is simple: Is there any way to enable a content script (through executeScript()) to be able to access an iframe on the current webpage (say stackoverflow.com) that has the same origin of the extension itself?
To put to rest: I realize you can communicate through postMessage, hashing, and so forth from the iframe script to its parent script, but my main goal is to add events onto the iframe directly from a content script rather than having to pass a message (and create a middle man).
I believe injected content scripts run on the page "in their own little world", in which the page itself, nor other content scripts can access, so it leads me to believe Chrome could possibly allow these scripts access to iframes of its own origin (the extension url itself).
EDIT
Just to clarify, the iframe would have a url of the chrome extension itself, under the protocol chrome-extension://. The parent page of the iframe could have any url, say http://stackoverflow.com for instance. So trying to access the iframe from a content script generally wont pass the same-origin-policy...The question is if there is a way around this using Chrome's Extension library.
Thanks!
You can certainly run a content-script on a page and interact with any embedded iframes. I was working on a project recently where I needed to do this.
I don't have a solution in pure javascript so this would require you to include the jQuery.js library, if that works for you.
In the content-script running on the parent page I did the following:
//CAPTURE FRAME LOAD
$("#frameID").load(function () {
//Create an object for the frame
var firstFrame = window.parent.frames[0].document;
//Set JQuery events to run in the context of the frame
$("#buttonID", firstFrame).click(function(){
//Capture click event of a button within the frame
});
});
Related
I was studying how Disqus and other embedded wigets are implemented, and I came to realize that they don't use an enclosing iframe where all their widget is run. What they do is to append elements dynamically to the embedding page through JavaScipt and then run almost every form or button in some iframe. What's the point of doing this? Couldn't they just wrap everything in an iframe and then change the parent window URL (to allow navigation) through some kind of cross-domain messaging system such as easyXDM? Can anybody point out some benefits that arise from having some elements not inside an iframe?
Code inside an iframe may not be able to set cookies as browser thinks it is an advertisement.
Iframe content cannot control the size of the outside iframe, so iframe needs to be created with javascript and javascript needs to be loaded externally so that external site has total over iframe size.
Happy new year :)
I have a Chrome extension which is a popup that contains an iframe, inside that iframe i load a whole web app. my question is
How can i communicate with the code inside that iframe form popup.html or from the background page? I would need to either read DOM elements inside that iframe or better be able to make js calls to different methods.
Thanks for all the help!
Use a content script that loads inside that frame. They can access the DOM of that page and make calls to the background page, though it's a bit harder to be able to communicate with the JavaScript on that page - but DOM elements should be fine if you control both the iframe and the extension.
See http://code.google.com/chrome/extensions/content_scripts.html
I am developing a webpage which our customers want to insert on their websites by wrapping my page in an iframe (cross domain). I don't need to interact with the parent or know anything about whats outside the iframe.
I am using HTML, CSS, Javascript and Webservices.
Question: How am I limited inside an iframe compared to if my page was running outside the iframe?
You're not. Any JS linked within the iframe from your domain will act in the context of the iframe. Aside from being crammed into an unusual container it should work the same as it would if it was loaded independently.
If your needs should change however, there are ways to send signals between parent frame and iframe if both pages have JS written to cooperate. There's methods using the # in URLs which can be read by the parent and don't force page reloads and I believe they share the window.resize event which can be fired manually without actually resizing the window.
UPDATE: There are far better ways to communicate between cross-domain iframes now than there used to be. Naturally you'll still require cooperating JS on both ends but you can use window.postMessage rather than triggering messages via window.resize and data after a hash symbol in the URL. That was a cool trick though.
When creating links you should have in mind to maybe use the target-attribute of the a-tag if you want to create a link for the parent window. Otherwise the new page would be loaded into the iframe.
We have an application that reconstructs external web sites in an Iframe from within our domain so we can use tools that run in the browser to inspect the external website. This is an unavoidable requirement since we need to gather information about the external page using JavaScript. If the page were not reconstructed from within our domain, we would run into cross site scripting issues.
The problem is that the scripts on some pages redirect out of the iframe, which stops our tool from working.
My query is whether there is a way to allow the scripts to run within the iframe, but not to affect the page that contains the iFrame?
Hope that makes sense - thanks!
No I do not thinks so.
If the Iframe is loaded from the same domain any script will have full access to the page.
The redirect out of the page you refere to is the page protection from Hijacking where another site tries to use the page contents.
By ridirecting out of an iframe they avoid that.
You could try using a separate window (window.open) to load the reconstructed external sites instead of an iframe. As long as they are at the same domain, they'll still be able to communicate, but the child window won't be likely to mess with your main window.
Alternatively, your outer window can do nothing, and be at a different (sub)domain from your control window. Your control window is an iframe in your outer window, and the reconstructed external site is another iframe sharing the same domain as your control frame. Now if your 'external' iframe tries to do something with window.top (besides navigate) it will fail because of the cross-domain policy, but your control iframe will share the same domain as your 'external' iframe, so you can inspect and manipulate it.
If you use the second approach, frames will still be able to navigate the top window. You can prevent it by adding something like this in the top window:
window.onbeforeunload = function(){return '';};
Now you'll be prompted with a dialog box if anything tries to navigate the page, and you can abort navigation. This will probably fix your current approach by itself, but it may be best to have the top window at a separate domain in case the external site tries to do anything unexpected with it.
Can the iframe access its parent if I changed its src to "about:blank" after loading it in the parent page?
Note: the iframe is in another domain not the same as the parent page.
No. If you change the src attribute of the frame to about:blank the content of that frame will be replaced with the blank document, and any javascript running inside the iframe will terminate.
If you need a way for the two to communicate, one of the ways to go is to expose some kind of JSON based endpoint that can be called from one of the domains, while the other polls for a result.
UPD: Regarding your pronto question, I would guess they don't use an iframe. Pronto is a bookmarklet, which allows code to run in the "outer" page. While I didn't verify this, I'd guess they are able to make the browser page load their JS library via an injected script element, and display their UI that way.
Generally, no. This is known as cross-site scripting (XSS) and is considered a security risk, so most browsers prevent it.