Creating a tweet button without opening a new window - javascript

I'm looking to add a "tweet this" button to a site. Simple enough, right? The catch is that the site is meant to run on an embedded platform that doesn't particularly handle popup windows, so I'm trying to do everything inside the page.
I'm able to successfully create my tweet button, attach an onClick handler to it, and construct a proper twitter.com/share URL for the relevant content. All works fine when I open that URL in a new window with window.open. However, if I try to open the URL in an iframe, nothing loads inside the frame. Even loading http://twitter.com into the iframe fails in the same way. However, loading Google or any other website seems to work just fine.
Any thoughts on what I'm missing here? Thanks! --zach
Edit:
Yep, they are detecting the iframe on load and blanking the page:
if (window.top !== window.self) {
document.write = "";
window.top.location = window.self.location;
setTimeout(function(){ document.body.innerHTML='';},1);
window.self.onload=function(evt){document.body.innerHTML='';};
}
Any reasonable way to get around this, or am I stuck writing my own auth pipeline through oauth? I don't need anything from their API, just letting users tweet to their own accounts.

Twitter (like Stack Overflow) is probably using some Javascript to ensure they're not being presented in an iFrame:
if(top!=self){
//hates you
}
I ran into something similar recently, and ended up re-doing part of my app without the iFrame element.

Go and get a developper account on twitter and things are made easy for you :)

Can you simply redirect the the twitter share URL? I'm guessing they want to be careful about opening the window in iframe's to prevent malicious sites from tweeting in a user's account without giving the user a chance to first confirm their intent to send this tweet.

You said window.open worked fine for popping up the url in a new window but have you tried popping it into the parent frame?
twtWindow=window.open([url],'_parent',[specs])

#yuval Unfortunately for you, the twitter url goes to a page that has the X-FRAME-OPTIONS:SAMEORIGIN header set in the response. It's not a Javascript check. The browser will simply refuse to render the page after seeing the header. This is done to prevent a clickjacking attack, usually done to steal a user's password.
So your only other option is really to redirect your current page with window.location.href=url.

Related

_blank got blocked as pop up how can i prevent this?

I have created a pdf on the server when i use:
function GetPdf(document) {
//Stores the data and creates the html,pdf file
$http.post('createpdf/', document).success(function(data){
console.log(data.filename);
window.open('download2/'+data.filename+".pdf", "_self");
});
I get a error message pop up blocked in google chrome.
When i use the option enable pop ups for this website it all works fine. Is there any way around this ? Because this could be confusing for some users.
But when i use:
window.open('download2/'+data.filename+".pdf", "_self");
It opens the page without warnings but then the main application is replaced by the pdf which is not the result i want to have.
Browsers have strict rules about when they allow JavaScript to show a popup, but they can be summarized as "Only in response to a user action".
Receiving a response to an HTTP request is not a user action, so popups are banned.
The simple solution here is to not use JavaScript. The point of Ajax is to communicate with the server without leaving the page, but you're going to leave the page anyway so there isn't really any point in using Ajax.
Just use a regular form submission.
<form method="post" action="createpdf/" target="_blank">
… then have the server side script redirect to the URL of the created PDF instead of returning the URL as JSON.
I guess you are using and external JavaScript library, I had the same issue on another Project, I used target="_tab" and it worked, I found this on this question.
It's the way Chrome handles popup calls from JavaScript when you use libraries, I used Moment.js to trigger a similar event and got the same issue.
Pop up blocking is not an issue, but a native browser feature that protect the users from popup-hell.
I would recommend to open the PDF in a modal popup instead of a new browser window.
With some jQuery code it is quite easy to implement: documentation is found here
You can always use an alternative route, for example instead of window.open function. You can use the window.location function, perhaps. Windows.location.replace which will relocate you in the same tab.
<script type="text/javascript">
<!--loc can be any changed to your window-->
var loc = "https://google.com/";
window.
window.onclick = function() {
window.open(loc);
}
</script>
Try that :)
window.open is being blocked because you are doing window.open without a click function. Most web browsers will block this feature for security purposes.

Detect if page was opened from app

This applies both to Android and iOS. My web page may be sometimes opened by an app (you go to the app, and click a link there which opens the page).
I want to know if the page was accessed through an app or if the user got to it, let's say, by typing the address on the browser.
If accessed through an app, I don't need to know which app it was.
The only thing I know of is document.referrer, but it seems to return "" when the page has been opened by the app. Unfortunately using "" as an indicator is not possible, as other ways of getting to the page may also show "" (for example typing the address). The history object does not seem to contain the info I'm looking for either.
I am using a Zendesk Help Center, so I only have access to the javascript of the page in order to detect this. I can't make changes on the server-side of my page.
Alternatively, I may be able to talk to the people in charge of the app so that they include something when the app opens the browser which would allow me to access that info on the browser, but I am not sure what that could be. Any ideas?
Thank you!
It seems to me like your best bet would be to have specific links for your site that will let you know that the link came from the app.
Like so: http://www.yoursite.com/?openedFromApp
You will use those links inside the app that will be directing users to your website.
That way, if you were using PHP as your server-side language you'd be able to check if the openedFromApp URL parameter was set like so:
<?php
if(isset($_GET['openedFromApp'])) {
echo "The website was opened by an app";
}
else { echo "The website was opened normally"; }
?>
If you want to check if the openedFromApp URL parameter is set using Javascript you'd have to create your own function for accessing URL parameters as Javascript does not have a built-in way of accessing them.
But this link could help you access the URL parameters with Javascript: https://stackoverflow.com/questions/...

Links that don't pass referrer

I want to create a list of links opening the targets in new tabs from my private page and I don't want the referring URL to be passed on.
I tried the following method, but it didn't solve the problem:
<script>
function op(url){
window.open(url.replace(/<(?:.|\n)*?>/gm,''),'_newtab');
}
</script>
<span onclick="javascript:op(this.innerHTML);">http://www.google.com<span>
Is there any way how to spoof or blank the referrer? In the worst case I might create an iframe and put the page with links on some free hosting, but I'd prefer some more elegant solution. The only requirements are tha t it should work in Chrome, Opera, IE and FF (2011+ versions), accessibility is not an issue, since it'll be used by very few users I know.
The referring URL is part of the HTTP protocol, not the mark-up. You can't change this.
Also, you never need to specify javascript: in an event handler. It's always is and can only be javascript.
There is a rel="noreferrer" which is not yet suported by Firefox...
See also https://stackoverflow.com/a/8957778/22470
Create a tiny app on Heroku that receives a URL then forwards the user.
You could redirect to an intermediate page that redirects to the final website, this would hide the true referer.
It seems the easiest is the iframe dirty way.

Javascript cross domain problem

Our website gives a widget to be installed in pages (a piece of Javascript that writes an iframe element and inside it renders things and you see rss, images, and other stuff).
I need, after the user do some stuff, to redirect the page (where the widget is) to another location, but using top.document.location is forbidden since the page and the iframe generated by the widget are in different location, and using window.open is usually blocked by popup blockers.
How can i do it ?
Try:
window.location.href = "url";
Although reading properties from the top window is disallowed, some of them are open to writing - and one of these are location.
Simply do
top.location = "http://foo/bar";
and it will redirect just fine.

Call the function only after the browser is fully redirected?

<script>
function test() {
alert("this should only be called after the browser is fully redirected?");
}
window.location = "http://google.com";
test();
</script>
I'm about redirecting the user guys to a page and I want to do something (call a function) only after the browser is fully redirected but I can't get it to work. Is there any way for me to do so?
Is there any way for me to do so?
Nope. When the page has opened google.com, you no longer have any control over the browser window.
Once URL changes, all execution of the current page is stopped.
Not really. You'd have to put the page you were redirecting in a frame and keep the script in another frame, then watch for the content frame to get updated. But you'd also run into cross-domain issues because of the Same Origin Policy (which governs access to one document's contents [the new page] from another document [the one containing the script you're running]). So basically, you can't do this.
If you post a separate question saying what you're trying to achieve by running more code afterward, it may be that people can help you with alternative approaches.
i don't believe this would work. it's a form of XSS/injection and therefore a security risk. i don't think the W3C allowed this sort of thing because it's very dangerous. as soon as the user is loading a different page, the browser ignores the previous one.
http://www.coderanch.com/t/439675/HTML-JavaScript/Javascript-call-AFTER-redirect
see that guy's answer for a visual

Categories