I am coding a Web app that needs to have multiple tabs/Web pages open. And I would like them to talk to each other. And I don't want the pages to talk to the server. So is it possible with HTML5/JS? By the way they are all on the same domain name.
I've never come across a webapp which used the browsers tab functionality as a means of navigating. I don't want to say it's wrong, because I don't know your particular requirements and, of course, I haven't played with every single webapp in the world.
However, would it not make more sense to implement your own tabbing system within your web app than rely on a feature of the browser which is probably inconsistently implemented and which may be affected by the user's personal settings?
If you're set on this path, and offline functionality is a definite requirement, then I think your only option is using the LocalConnection feature of Flash, as Brad suggests in the comments. I imagine you could create a bridge with ExternalInterface to pass any data from Flash to the page. The Flash would need do nothing else but marshal the communications (it could occupy a single pixel somewhere on the page). This is a similar approach to the one the dojotookit took with their Flash storage, designed to provide a more capable alternative to cookies.
I think the answer here is that what happens in the view, doesn't have to reveal whats happening behind the scenes.
You can make DOM elements on a page communicate with other DOM elements on the page without making a asynchronous call to the server if thats what you're asking.
If you have two tabs in the.. lets say chrome browser, and you want one DOM element to talk to another DOM element on a completely different browser tab. You have to make that asynchronous call to the server which will shoot one back to the other tab. But you don't have to show that happening in the view :) (This can be done with Node.JS/Socket.io, an example would be a chat room built with HTML5/JS)
Hope this helps
I know this is an older post, but you may want to look into local storage, or even cookies set via javascript.
There are 2 reliable ways you can have pages in other tabs (or across iframes) talk to each other.
The postMessage API allows pages to send messages even when they are on different domains. There are some security issues to be aware of to avoid malicious behavior. You can read about that in the linked article.
localStorage and sessionStorage will dispatch a "storage" event when they are changed. Using this event you can be notified in other tabs when the data has changed. This only works within the same domain. Because this is all you need, it might be the wiser option to avoid any security issues.
Related
As RIAs and SPAs (or web apps with heavy javascript usage) have become more and more popular, I've been running into systems that, instead of using good old a href hyperlinks, I see them utilizing constructs using onclick with JavaScript code that manipulates navigation. This is particularly true with images.
For example, instead of seeing something like this:
<img src="...."/>
<div ... onclick='SomeJsFunctionThatNavsToAnotherPage()'><img src="..."/></a>
What is the advantage of this? It makes it incredibly hard to trace where pages transition to when debugging or trying to root cause a bug. I can get the idea when the target to navigate can change (so yes, here you could use a function that computes to what page to navigate to.)
But I see this pattern even when the pages to navigate to are constant. I find this extremely convoluted and hard to test. Not to mention that there is always the browser-specific bugs that come from stuff (sadly in my experience from over-complexifying the front-end.)
But I am not a RIA/SPA developer (just backend and traditional web development). Am I missing the rationale behind this?
TO CLARIFY
My question is not for the case when we want to redraw the page or change current content without changing the current location. My question is for plain
old transitions, from page A to page B.
In such a case, why use onclick=funcToChangeLocation() over <a href="some location"/>.
This has been a pain for me when troubleshooting systems that are already written (for I wouldn't write them like that), but there could be reasons I am not aware of.
Again, my question is not for pages that redraw themselves without changing the browser location, but for navigation from one page to the next.
ALSO
If you are going to vote to close this question, at least leave a message explaining why.
If you are making a web application, sometime you don't want to redirect the user to another page, but you want to dynamically change the content of the page without refreshing the page. It has some advantages. It can be faster. You can easily keep the state of the page/application. You are not obligated to communicate with the server. You can update only a part of the page.
You can also dynamically request data to print the page. If you are displaying an user profile page, you can only ask a json object that represent the user. This json object is smaller than the whole page and will be dynamically rendered. It can help to reduce the data transfer between users and server when your bandwidth is limited.
EDIT: In the case of a simple page redirection, I think it's a bad practice and I cannot see an advantage. I think it obfuscate the website when the google crawler try to parse the website.
I once had a pretty successful web directory website. One day Google decided that "directories" are competing businesses and started penalizing sites that had links on directories. I used the method you describe to cloak outgoing links to try and trick Google.
I see this site and many others answering similar questions, but often in ways I fail to understand or just do not make sense. And often in contradictory ways (maybe the spec keeps changing?). And I see posts about how to set up cross domain JavaScript communication, but I do not need to communicate with this external content (and I am still not sure if you must have access to the code-base of both child and parent or not, for these hacks to work).
I need to show another person's webpage, on another domain, in a box on my page.
SO basically this is like clicking a link, but instead of specifying that the browser should open this in a new tab or a new window, I want the browser to open it in a in-line frame type deal on the current page. So even I know enough about security to know that there are no security/communications issues with this feature.
But assuming that the browser developers have removed this completely reasonable feature, how do I go about doing this? I have heard talk about some Json data type thing being allowed, but still have not figured out exactly what that means. Can I contact any random external page and get some json summery of the page, or how does this work? (I saw an example with Wikipedia, but I was not sure exactly what was being returned, and if any random URL would work just as well).
I can use PHP for this, but that is just stupid. I would basically just be setting up a proxy to access content I am randomly banned from because of the programming language I am trying to access it from.
You are looking for iFrames. Note, however, that there are many security restrictions due to potential cross-site scripting vulnerabilities through improper implementation.
You can change the source of that internal frame by simply editing the source attribute of that iframe
I am interested in making a website that flashes through a visitors entire web history when they visit. I plan on using JavaScript to grab the history on each viewer's computer and animate through it with varying speeds depending on how much they had. My thought was to use history.length to determine the length of the visitor's history, and then use history.go() to navigate -1, -2, -3, etc. through the entire web history. I recognize that load times would be HUGE, but right now I am just trying to think through the concept. This related question seems like what I would use for the basis of my code, however, I don't understand why they describe that this method would not work. I am a student who is very new to JavaScript.
Do you guys have any knowledge of whether or not this will work, or any ideas on ways to achieve my idea?
You can call history.go() once. That's about as far as you'll get. The reason is simple, once you're on the previous page, your javascript is gone. Iframes won't work either due to the fact that you can't execute your own JS in an iframe that has a page from another domain. Read about same origin policy for more info on that.
The only real solution I can think of is a browser extension. The reason that'll work is due to the fact that your JS can persist across multiple sites. You'd probably just need a userscript in each page that does the following:
check a variable to see if the functionality is enabled
if it is, call history.go(-1) after a timeout (to control the speed)
I'm most familiar with Chrome so I'm imagining a browserAction to enable/disable the script and a content script that does the redirect. Other potential options include Greasemonkey (Firefox), Tampermonkey (Chrome), Personalized Web (Chrome) scripts
As stated in the question you linked to, JavaScript and / or the DOM does not give you access to the entire browser history since that would be a severe privacy violation. Imagine going to a site and having them be able to know every site you ever visited in that browser.
This would potentially give the site access to:
Sessions you are still logged into on other sites (if they store the session key in the URL, as some sites do)
Insight into what kind of activities you perform (are you a moderator on site X?)
Enormous amounts of data on what you are interested in.
This is not something that standards bodies or browser manufacturers thought users would be interested in sharing with everybody. That's why there isn't an API to walk through the browser's entire history.
#sachleen has already provided a very nice in-depth answer on how you can get around this limitation for individual browsers if you want to build this application. For the sake of completeness I'll simply mention the key term: "browser extension". :-)
I am needing to a custom widget into users of my applications websites and the initial thought it that an iframe would make it SO much simpler for a few reasons:
I can use the custom framework built for the application which provides a ton of pre-built code and features that i'll be using in the widget and thus wouldn't have to recreate. Cross browser event handlers and prototyped objects are just a few of many examples.
I don't have to worry about clashing with CSS and more specifically
won't have to use inline css for every dom element I create.
Cross domain requests are not a problem because i've already built
the functionality for everything that needs to be communicated using
jsonp, so don't let that be a downside for an embedded dom widget.
The idea as of right now is to write a quick javascript snippet that is essentially a button and loads a transparent iframe above the window that is full screen. This will give me control of the entire view and also allow me to write the widget just like I would any other part of the parent application. Maintaining the same json communication, using the same styles, using the framework etc. Clicking on any part of the iframe that was is not part of the widget (which will likely load centered in the middle of the screen, and be full screen if on a mobile device) will dismiss the widget and resume the user back to their normal navigation within the website. However, they can interact with my widget while its up, just like it were an embedded portion of the website that happened to load a javascript popup.
The widget itself does communication somewhat heavily with the server. There is a few requests on load, and then as the user interacts, it typically sends a request, changes the view and then wait for another response.
All that being said, is this a bad idea, or otherwise unprofessional idea? Should I put the extra work into embedding the widget directly into the hosts DOM and rewrite all the convenient framework code? I don't have a problem doing that, but if an iframe is a more appropriate choice, then I think i'd rather that. My only limitation is I need to support down to IE8, and of course, the widget needs to be viewable on both desktop and mobile, and the widget cannot be obtrusive to the clients website.
Some good reading from another post. Although closed, it poses some decent arguments in favor of iframes.
Why developers hate iframes?
A few points that resonate well:
Gmail, live.com, Facebook any MANY other major websites on the
internet take advantage iframes and in situations where they are
used properly...well that is what they were made for.
In situations especially like mine its considered a better practice
to prevent any possible compatibility issues with a remote website I
have no control over. Would I rather use an iframe, or destroy a
persons website? Sure I can take all possible precautions, and the
likelyhood of actually causing problems on another persons site is
slim, but with an iframe its impossible. Hence why they were created
in the first place.
SEO in my situation does not matter. I am simply extending a
javascript application onto remote users websites, not providing
searchable content.
For the above reasons, I think that taking the easier approach is actually the more professional option. Iframes in general have a bit of a misconception, I think because of their overuse in ugly ways in the past, but then again tables also have that same misconception yet believe it or not, when data is best displayed in a tabular fashion, it makes sense to use...wait for it...tables. Though we do this behind css values such as display: table-cell.
For now iframes get my vote. I'll update this answer if a little further down the development road on this project, I change my mind.
I have a page which displays a different website (say www.cnn.com) in an iframe.
All I want, is to make links inside the iframe open in the parent window, and not inside the frame.
I know that this is normally impossible for security reasons, which makes good sense to me. However, the page I'm working on is not going to be public, but only on my private computer, and if I have to switch off certain security features to make it work, it's OK.
Is there any way at all to do this?
I have been combing through the web all day for a solution. If I missed a post here or elsewhere, please point me to it.
I read that in Firefox (which I'm using), it's possible to get extended permissions in javascript if the script is "signed" (or a particular config entry is changed). However, I don't know how to exploit these extended permissions for my purpose...any hints?
I'd also consider different approaches, e.g. not using iframes at all. Whatever the method, I want to be able to embed several websites, which I have no control over, within one page. Links clicked in any of the embedded websites should open in the parent window. It's just supposed to be a handy tool for myself. I should say that I have basically no knowledge of javascript and am just learning by doing. If you can confidently say that what I want is not possible with any client-side methods, that would help as well. I guess it would be rather straighforward to do it e.g. with php but I don't want to setup a webserver if it's not necessary. Thanks for any tips!
This is a bit different solution than you asked for, but might be a better way to attack the problem as it might give you the ability you seek without compromising any normal web security.
I wonder if Greasemonkey (add-on for Firefox and other browsers) might be a useful solution for you as it allows you to run local javascript against other pages to modify them locally, somewhat regardless of normal security restrictions. So, you could run through all the links in a CNN page and modify them if that's what you needed to do.
To use it, you would install the greasemonkey add-on into Firefox, write a script that modifies CNN.com the way you want to, install that script into Greasemonkey, then target the script at just the web page CNN.com. I think it should work on that site whether it's in an iframe or not, but your script could likely detect whether it was in an iframe if you needed to.
It would appear the HTML5 seamless attribute would be what you are looking for. But it doesn't appear that anything supports it yet...
http://www.w3schools.com/html5/att_iframe_seamless.asp