I have need to communicate between two iframes of the same domain, which live inside a parent page on a different domain that I have no control over.
This is a Facebook app and the basic layout is this
apps.facebook.com/myapp
L iframe1 (src='mysite.com/foo')
L iframe2 (src='mysite.com/bar')
I need frame1 to talk to frame2, but in Opera I can't access window.parent.frames['frame2']
to do the usual cross-domain methods (updating location.hash for example)
Is there an alternate way to accomplish this in Opera?
Thanks for your help in advance
Did you try using HTML5 web messaging. It is quite well supported currently by recent versions of browsers.
iframe.contentWindow.postMessage('Your message','http://mysite.com');
The postMessage property will need the origin http://mysite.com.
Generally no. Same Origin Policy denies you the possibility of communicating upwards to the parent, which would be necessary to then step downwards to the other frame. This is true in any browser.
If the parent document has given your frame-to-be-contacted a unique name, there is a limited form of communication possible with it by getting the user to click a link with href="otherurl#message" target="name", which will navigate the target frame by changing the hash without reloading the page, as long as the URL matches exactly. In Mozilla you can also do this with a form target, allowing you to script its submission (since link clicking cannot be automated), but not in Opera. Probably not much use... don't know if FB gives you a frame target name in any case.
You can make a communication channel between scripts in the same domain by using cookies(*): one script writes a session cookie, the other script polls for changes to document.cookie to find messages in it. But it's super-ugly and requires some annoying work to control signalling which messages are meant for whom when there are multiple documents open simultaneously. And there are further limitations for cookies in third-party frames (you will probably need to write a P3P policy to get IE to co-operate).
(*: or, presumably, HTML5 web storage, where available.)
As others have said, use window.postMessage. But instead of using window.parent.frames['frame2'], try window.parent.frames[x] where x is the position in the node list of the other iframe.
You can see an example of doing this across origins here: http://webinista.s3.amazonaws.com/postmessage
Related
I'm building a website for a client (real estate), and on the website are links to a different website (adverts for properties). My client routinely activates and deactivates these adverts when he rents out a certain property.
The hrefs on my links look something like this:
<a href="https://domain.xx/estate/idxx/des-crip-tion-xx-xx-x-xx/">. If the advert is indeed active, it just takes them to the advert. If it is not active, however, the website in question redirects the user to https://domain.xx/estate-for-rent/city/, effectively sending the users to my client's competition.
I wish to implement some logic where, before handing the users over to the other website, the server checks to see if it is redirected to https://domain.xx/estate-for-rent/city/, or some similar logic, and if so, uses preventDefault, or something, and notifies the user that the advert is not available instead of sending them to the other website.
I wonder if I can use the fact that only if the advert is active does the resulting url in the users browser window (after they've been directed to the other website) match the url in my href. Can i somehow get the server to try to access the url in my href, and have it see where it gets redirected, and then do something based on that? On the back-end, I'm running NodeJS with Express by the way, and if it matters, I'm relying heavily on EJS for templating. Thanks in advance for any help!
This sounds more like a problem you could solve on the client as opposed to the server. For example, at a high level here's how I would do it:
Handle the click event for each link (really simple to do a catch-all with jQuery)
Fire off a HEAD request via AJAX to the destination URL (this would be much more efficient than a GET but depends on the external service supporting this verb)
Use the status code to determine what to do next (e.g. 2xx allow redirect, 3xx pop a message and block)
When should I have addresses with # and when should I have separate address for each page or part of a page.
For example
https://ca.news.yahoo.com/nick-hornby-boys-read-telling-101350029.html
I know sometimes we need to have #, for instance when we call a javascript method to show a lightbox(modal) but some websites are using it in their unique address of their pages.
For example icloud is using it to show its modal when you click on create one now link.
https://www.icloud.com/#
However, as I said some websites are using that as a method to have unique addresses for their pages.
For example following address that is showing a single page of icloud website.
https://www.icloud.com/#find
Is that correct to follow this practice of having # in our unique address of the website pages similar to what icloud website has?
I am not asking about icloud.com thats just an example. What I meant is that if you go to www.icloud.com/#find page you would see it is not a single page website because there is just a header, login page and a footer. So why they are using #find and not something like find.html? Is there any specific reason that I am missing?
URL fragments(#whatever) are a way to address sup-parts of a document. You should keep in mind that these are never sent to or seen by the server so you can't really use them serverside to differentiate between URLs. You can use them to make parts of a static page addressable or, with the right amount of JS contortions, use them as a foundation for addressable navigation within a single page app. Some JS frameworks rely on this fairly explicitly although with is starting to go out of style as most browsers now support the history api.
Can Chromecast be used to display a web site or web app? All the sample sender/receivers I've seen so far show how to play videos. The docs posted so far are minimal as best, just an API reference with little explanation what any of it does. I just want to send a URL of my choosing and have that page displayed on the TV. There's no user interaction required past that point. Assuming that's possible, does anyone have sample Chrome sender and receiver code for that?
I was able to modify the Github sample Project > googlecast/CastHelloText-chrome
to show a web page.
In the receiver.html file, I replaced the DIV with an IFRAME and styled it for 100% width and height.
Then in the displayText() function I changed innerHTML to src.
The only modification made to the sender chromehellotext.html was to replace YOUR_APPLICATION_ID with the app id created by registering the receiver.
Note that some sites like Google and Yahoo will not display inside an iframe. If you really needed to do that you could skip the iframe and just set window.location.href to the URL. That, of course, will overwrite your receiver code so the only way to change URLs would be to manually disconnect first and reload. I tried using window.open instead but that did not work.
One could imagine writing a Custom Receiver that has an iframe that wraps any website. Your sender would could then send webpages to your receiver, and the onLoad would set the the URL of the iframe. Don't have any code, but it's fairly simple to write.
There is a simple way to do that with the hellotext sample. You can send the html by typing that into the text field.
<iframe src="http://mywebpage.com" style="width:1280px;height:720px"></iframe>
To provide extra info from the current answer, as this post comes up near top on most searches.
Thing to search for is Digital Signage, this is the sort of industry word.
following GreenScreen Chromecast works okay. Greenscreen
host solution is Sign Simple - which looks to be same approach as Greenscreen without you needing to host the receiver web page.
Similar hosted solutions using Raspberry Pi can be found.
Of note: with GreenScreen and the CastHelloText, I could not get 1080p only 720p, some comments mention Video only in 1080p, but Images in 720p, which I take to mean html pages aswell.
Chromecast can indeed be used to display an arbitrary URL.
This can be done from plain old Chrome, using 'url-cast-receiver'. (Usable 'demo' page, GitHub project page.)
I'm writing an extension that needs to show a page action on amazon.com pages.
Would it be better to request the "tabs" permission or to inject a content script into amazon.com pages?
The tabs permission strikes me as using less resources (because it just checks the URL against a regex in the background script) but I think it's a scarier permission message ("access your tabs and browsing activity")?
Injecting a content script into amazon.com pages seems like it would take more resources it but would only need permission to amazon.com...
It is a generic question and answer depends on Client to Client. You have pointed out the + and - of each.
I suggest you to go for content scripts if your clients are particular about security and privacy, in this you are adding an extra load to pages(with content scripts and message passing) which may slow down the normal execution process.
I suggest you to go for tab permission, if you are all about performance. It is a native API, and executes in background page no extra load on tabs. Many extensions on web store does use tabs API, i dont think this would scare them as this is not new.
However, it is all about your target section of users.
It is a well known problem to every web developer. As far as I tried to find a good solution to this problem - there was none (or at least I could not find it).
Lets assume the following:
The user does not behave, as he was expected to. The actual project I'm working in uses a navigation within the web portal. But if the user uses the browser's back button, the whole thing becomes jeoprady[?] and the result was not always predictable.
We used the struts framework and stored the back-url into forms - at some places, where we needed a back-url - this has been rendered out of this form's back-url. For there was only a singe field for this information and therefore it was not possible of going back multiple steps.
When you change the "struts-flow" - which may result in using a different form - this information will be lost.
If the user dares to put a bookmark somewhere within your webapp - this information may never have been set and again the result will again be either unpredictable or not flexible enough!
My "solution":
I was storing every navigation-relevant page the user visited onto a stack-like storage into the session. This means a navigation-path is collected and stored for later navigations.
At any page within the webapp, where back-navigations are involved I used a self-made tag which renders the stack-content into the url.
And thats it.
When this back-url was clicked, the stack has been filled with the content from the back-url clicked by the user (which holds all information from the stack once the back-link was rendered).
This is quite clear, because a click on a link is a clear state, where the web developer exactly knows, where the user "is" a this very moment - absolutely independant from whatever the user did before (e.g. hitting the browser back button multiple times). Then the navigation stack is built upon this new state.
Resumé:
It becomes clear, that this won't be the best solution. But it allows storing additional information on the stack like page parameters and some other useful stuff (further developments possible).
So, what were your solutions to this problem?
cheers,
mana
The stack solution sounds interesting, but it will probably break if the user chooses to navigate "in parallel" on different tabs or using bookmarks.
I'm afraid I don't really understand why you have to keep all this state for each user: ideally the web should follow the REST principle and be completely stateless. Therefore a single URL should identify a single resource, without having to keep the navigation history of each user.
If your web app relies heavily on AJAX, you could try to implement something like GMail (admittedly, not so easy...), where each change in the interface is reflected in a change in the page URL. Therefore each page is identified by the current URL and the user can navigate concurrently or use the back button as usual.