I am receiving the location of a pdf document in angular, and I cant get it to consistently download.
It works on my home laptop, but not whilst at work.
Code below
RenderService.document('document.pdf', spec).then(function(pdfLocation) {
$window.location = pdfLocation;
});
Works in Chrome on Ubuntu at home, not on the same set up at work. Does anyone know any reason why the operation of '$window.location' wouldn't be idempotent?
Update:
Also works on FF on my work machine, just not Chrome
This mostly happends if you have some third part software installed or the browser security is configured as to high. Check for addblocker & antivir software on your machine and also check the security configuration in your browser. Ensure that your pdf location is based on HTTPS if your application is running on HTTPS.
For Chrome & Safari try to set your window.location.href property instead of window.location. This should work for all browser so.
RenderService.document('document.pdf', spec).then(function(pdfLocation) {
window.location.href = pdfLocation;
return false;
});
Here is a plnkr demo which does run well in chrome.
Thanks to #lin I realised the issue was chrome blocking my download due to the advanced security option in Chrome:
"Protect you and your device from dangerous sites"
I'm not sure how to get around it yet, and will update this answer if I find a solution
Related
Apologies that this is a long question, I wanted to make sure it was clear what the problem is and, just as importantly, what it isn't - because I know there are a lot of questions that seem related but they don't seem to be about quite the same issue:
The web application we're developing at work needs to open a URL in a new tab when the user presses a particular button, after an API request has completed. The URL in question happens to open a PDF document.
We're aware of the issue with popup blockers, so are opening a blank tab straight away when the button is pressed, then setting the location to the URL a short time later after the API request completes. And this is working fine on desktop browsers as well as on Safari on iPad.
But there is a peculiar problem with Chrome on Android - at least we have observed the problem on Galaxy tablet versions 6 and 7. I'm aware that for some reason Chrome on Android does not have a built-in PDF viewer - however, it seems that accessing the PDF should trigger the OS to ask the user which app they want to use to view the PDF, and we are OK with that. What we do not want - but what is happening at the moment - is the PDF simply getting downloaded in the background, and the user not being given the option of viewing it directly.
From my research on how browsers handle PDFs, it seems this behaviour is dependent on various response headers - notably Content-Type and Content-Disposition. But we are doing this correctly as far as I know - the Content-Type is application/pdf and there is no Content-Disposition header so it should default to "inline", ie opening up to view rather than downloading. And I have tried adjusting the backend to send this header explicitly, both with and without a filename parameter - with no change in observed behaviour.
I strongly suspect this is a bug with Chrome and/or Android, but I cannot find it clearly reported anywhere. The key thing is that there is a delay in setting the URL - because if I put this directly into the console (which I can do when running browserstack from my desktop; not sure if there's any way to input it into a real device directly):
function test1() {
window.open("url/for/my/pdf");
}
this works fine (the device prompts you with a choice of how to open the PDF)
but not with either
function test2() {
const newTab = window.open();
setTimeout(() => {
newTab.location = "url/for/my/pdf";
}, 1000);
}
or even with this, non-asynchronous, version:
function test3() {
const newTab = window.open();
newTab.location = "url/for/my/pdf";
}
Both test2 and test3 above, when called from the console, result in the PDF being downloaded rather than viewed. And this isn't specific to our endpoints - I've tested it with URLs to various random PDF documents I've found online, and the same behaviour occurs.
So my questions are:
is this a known bug with Chrome or Android?
whatever the answer to 1) above, is there any straightforward workaround which will ensure the user is always prompted to open an application to view the PDF, rather than simply downloading it? (Bearing in mind that we can't avoid the delay between opening the tab and setting the location - or at least this is our preferred way.)
Thanks in advance!
I am building a web app that uses js-cookie. I use the following to import the js-cookie library into my html/javascript file:
<script src="https://cdnjs.cloudflare.com/ajax/libs/jscookie/2.1.4/js.cookie.js"></script>
My js-cookie code works perfectly with Android devices: Cookies are created and retrieved, just as expected. However, the same code fails to write/read cookies when executed on iOS devices (iPhones). The browser doesn't matter; I have tested with the latest versions of Safari, Chrome, and Firefox for iOS.
The cookies, when written, come back as undefined when I attempt to read them on iOS devices. Here is a snippet of code that I use to write the cookies:
//Set expiration cookie...
nowDate = new Date();
expiresDate = new Date(nowDate.getTime() + (120 * 120000));
//cookie expires in 4 hours
Cookies.set('expires', expiresDate, { expires: expiresDate });
Any subsequent attempt to read these cookies works perfectly on Android devices, but not on iOS devices. Here's an example piece of code I use to read the cookie:
expiresCookie = Cookies.get('expires'); //get expiresCookie
What am I doing wrong?
The browser you use on iOs has no impact because, it's always the Safari engine. On iOs, chrome, firefox and others are just frame around the safari webview. That's for the pro tip.
Now, in your problem. Can you access to the classical cookie API ? You can do it using this :
document.cookie
If no, you have a very big problem. Maybe you've already moved to iOS 11 and be included in the no-more-cookie policy :
http://adage.com/article/digitalnext/ios-11-kill-cookie/311444/
Or maybe you have enabled an ad-block/do-not-track feature.
First, I think you have a trouble with you link to the script. If you did your first tests on android maybe your device still keep this file in your cache.
try with this url for having latest version: https://cdnjs.cloudflare.com/ajax/libs/js-cookie/latest/js.cookie.js
Then, check also that your url is not in file location (file:///.../file.html) instead of http (http://domain/file.html). Browsers doesn't save cookies when there is no domain and no http communication.
I'm building a website using WordPress as a backend, and AngularJS as the frontend. I'm using the WordPress JSON API to get my data to the front-end.
https://wordpress.org/plugins/json-api/
The problem
I'm using AngularJS to get my data from the WordPress JSON API. I have created the following service:
this.getPage = function ( slug ) {
return $http.get('wordpress/api/get_page/?slug=' + slug)
}
I use this service in my controller to get the current page like this:
HTTPService.getPage('home')
.success(function ( data ) {
$scope.page = data.page;
console.log(arguments);
})
.error( function () {
console.log(arguments);
})
This is working fine in all browsers, except for Safari on iOS. On Safari on iOS I get the following response when I log the error arguments:
This is the safari debugger which showed when I connected my iPhone to my Mac. The error response which I get is error code 0..
What I have tried so far
I have set Access-Control-Allow-Origin "*" in the .htaccess file, but this doesn't seem to work. The request is done on the same domain with a relative URL, so I don't think that this is the problem.
So, does anyone know why this is not working on Safari (iOS)?
EDIT
Some extra information as requested:
I'm pretty sure that this is due to the fact that Safari is the only browser that has the policy of blocking "3rd party cookies and other website data" by default. Actually, this issue shouldn't be exclusive of Safari iOS, it should also happen with Safari on your OSX. I'm pretty sure that if it's not happening in your MacBook is because one day you changed the default settings of the "Privacy".
You can try this, open Safari, go to "preferences" and under the tab "Pricacy" check if you have the option: "Block cookies and other website data" set to "From third parties and advertisers". This is the first, and the default option in the modern versions of Safari.
In your MacBook it will look like this:
And in iOS it will look like this:
Just to confirm that this is in fact what's causing your issue: change this setting to "Never", clear the cache and try to reproduce that problem again. I'm quite confident that you won't be able to reproduce it.
Now, if you set it back to "Block cookies and other website data: From third parties and advertisers" and you first clear the cache, you will have that problem again (with either iOS or OSX). After you've confirmed that this is the cause of your problem, set this setting back to "From third parties and advertisers", so that you can reproduce and address the problem with the default settings.
Bare in mind that every time that you want to re-test this issue you will be better off clearing the cache of Safary. Otherwise it could happen that Safari decides that the site serving the API can be trusted and you won't be able to reproduce the issue. So, just to be sure, clear the cache every time that you test this.
I believe that the root of this problem is that Safari wants to make sure that the user has had a direct interaction with the page that it's serving the "3rd party content" before the main page loads that content.
I would need to know more about your project in order to suggest an "optimal" solution. For instance: will the final app be integrated under the same domain as the API? Because if that's the case, you shouldn't have that issue when you go to production. I mean, if the app that you are developing will be hosted under: http://whatever.yourDomain.org and the API is going to be part of that same domain (yourDomain.org), then you shouldn't have that issue at all in production.
On the other hand, if you need to have have the API hosted under a different domain, then you will have to find a way to "trick" Safari. Have a look at this:
Safari 3rd party cookie iframe trick no longer working?
And this:
http://www.allannienhuis.com/archives/2013/11/03/blocked-3rd-party-session-cookies-in-iframes/
I hope that this helps.
When I try to include social media scripts into my page, I get the "pending" status in Chrome on some computers (not all of them):
https://s17.postimg.cc/xvpjllmwv/image.png
In other words, the scripts are not loaded. The scripts are included via the default way as recommended by the developer's guide.
What settings of Chrome may cause such behavior?
This is due to the Ad-block or some plugin you are using with the chrome. Disabling the ad-block/plugin which blocks the requests will fix your issue. It blocks all the requests and so it is pending.
Try to fix this way and share the status.
Are you using HTTPS on the site?
If you are, chrome blocks http requests within https websites and shows a gray shield near the bookmark star on the url bar.
If this is the case just include your external stuff without specifying protocols
Example:
Change
http://domain.com/some.js to //domain.com/some.js
Answer repeated from this question.
I had the same issue on OSX Mavericks, it turned out that Sophos anti-virus was blocking certain requests, once I uninstalled it the issue went away.
You can also try disabling extensions in chrome to see if that helps, if so you'll know an extension is causing the problem. Use the '--disable-extensions flag to see if it fixes the problem.
I was using AngularJS as a front-end framework for my app, and somehow $httpProvider.defaults.withCredentials = true; made all my POST requests pending. After I removed this line, everything run instantly.
Sometimes the script takes more time in loading while the system has moved on. so make sure you wait for get to give you response before you manipulate it.
so rather then doing following
var temp;
$.get('path/to/filename.ext',function(data){
temp = data;
}
//use temp
do this
var temp;
$.get('path/to/filename.ext',function(data){
temp = data;
//use temp
}
we spent three days still could not solve a strange technical problem, so we need your help.
The pac (proxy-auto-config) file we write is working fine in all other browser, except IE(Internet Explorer).
the request url is
https://news.google.com.hk/nwshp?hl=zh-CN&tab=wn
if pac file is
function FindProxyForURL(url, host) {
if(/news/i.test(url)) return "PROXY 127.0.0.1:8087";
return "DIRECT";
}
it is right, it is using proxy to visit the website.
however if the pac file change to
function FindProxyForURL(url, host) {
if(/CN/i.test(url)) return "PROXY 127.0.0.1:8087";
return "DIRECT";
}
CN, is also in the url. but IE do not using proxy to visit the website, like we think.
However we test in other browser like Chrome, Safari, Firefox, they all run well , they all using proxy to visit the website.
It seems like in the IE, the parameter "url" in the function FindProxyForURL(url, host), is not full path of url, it just contain the host，but in other browser it is the full url.
We have taken 3 days on this problem, Do you have some idea to let the function in IE pac file to get the full url, or have a method to debug the pac file in IE browser.
We even cannot alert infomation in browser.
Our IE version is 10, Windows 8.
See http://support.microsoft.com/kb/271361
You need to set HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\EnableAutoProxyResultCache to DWORD 0.
for future research, and anyone who stumbles upon this thread, this Microsoft blog, describes why this did not work, it is because of some recent changes in how IE 11 can use proxies.
http://blogs.msdn.com/b/ieinternals/archive/2013/10/11/web-proxy-configuration-and-ie11-changes.aspx