I've got a program that needs to juggle multiple iFrames at once that each communicate to the main window with postMessage.
I need to find a way to see what iFrame element sent a specific message.
I've tried using message.source however it only shows a Window element from inside the frame (that cannot be read as they're sandboxed). That excludes the possibility of finding it via the iFrame's contentWindow.
Related
I need to accomplish something very similar to the "inspect element" functionality with Chrome developer tools (see attached screenshot).
The main thing I'm looking for is the ability to recognize and highlight an element on the given page. I can display an overlay, add a class to the element, etc. I know that using an iFrame and trying to access and manipulate the DOM w/in the iFrame won't work directly because its cross-domain. I also know about post messages if you have control over the site, but I may not have that all the time. The main issue I have is that I am only trying to temporarily highlight elements on a page as if I had clicked "inspect element" and displaying that. It doesn't need to persist or anything, just to highlight specific elements (h1 tags for example), when the user loads a website within my app. Even the ability to use the chrome developer tools where it lets you "edit as HTML" would work if there were a way to do so.
Is there any way, using an iFrame, a new tab, or any other means that I can use to highlight elements on a given website who's URL is provided? I've attached another image of the "goal".
It seems like you have three options to highlight the elements.
1. Browser Extension
2. Send events through postMessage to direct the iframe site to manipulate its DOM
3. Send events through postMessage to receive information about the positioning of the DOM and overlay elements on top of the iframe.
#1 seems to be a longer overhaul to do. #2 and 3 is only possible if you will always have access to the website in the iframe.
https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
The window.postMessage() method safely enables cross-origin communication between Window objects; e.g., between a page and a pop-up that it spawned, or between a page and an iframe embedded within it.
I need to pass a message from an iframe to the parent window. The parent window and iframe window are from different domains so I am running into difficulty with same origin restrictions (i.e., my attempts to access window.parent from the iframe are blocked).
I have been able to pass messages from the parent window to the iframe using the window.location.hash method as described in this article. However, the method does not appear to work for sending messages from the iframe to the parent window.
I must also find a solution that works in IE7 and IE8.
Does anyone know how to do this?
I'm about to give up and build a web API to facilitate messages from the iframe to the parent window.
Take closer look at window.postMessage API. It allows you to send message across all domains and between iframes. Perfectly works on IE as well
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.
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.
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.