I am writing a page (html, javascript) that is going to be used absolutely for mobile devices.
This page is going to serve some files (typeof: pdf, doc, docx and many others) that browser doesn't recognize. How can I force browser to give the option of saving file and open it with the appropriate installed app?
I tried _blank but nothing, it opens the page and ... raw data appear (not even a new tab starts).
It sounds like you need to make sure the web server is serving the correct mime-type for your content. For uncommon or forced-download types, it can be served as application/octet-stream.
Related
Good day,
I have a system that renders large amount of data through pdf ( 30mb + ). Now I want the user to view pdf first so he can either download it or just print it right away. as of the moment I am forcing the user to download the file since open( 'datauri here' ) wont work with larger files.. the problem with downloading is that files are multiplying and consumes space over time and also its not necessary for me to download all files that that they want to print right away.
I need a functionality that is similar to chrome's preview when using windows.print
can you please suggest any ideas or other things to do this?
I am currently using javascript library to create pdf (pdfmake). I am also using chrome as my main browser
You would have to make sure that the PDF is optimized for fast web view, and that your server is using the byteserving protocol for serving the file.
If that is the case, a useful PDF viewer (such as the web browser component provided by Acrobat/Reader) understands this protocol and requests (after the first page plus overhead of the PDF) only the data for the pages which are to be displayed.
A quick search did, however, not reveal whether the Chrome PDF viewing component is smart enough to understand the byteserving protocol.
My chrome packaged app contains a PDF, and I would like to let the user view it. If I open it in the current frame I get the error "Chrome PDF Viewer is not Allowed".
Frankly, the chrome PDF viewer is pretty awful, so I'd rather let the user view it in their PDF viewer of choice anyway. If I disable the chrome PDF plugin (just as an experiment) and I try to open the PDF using chrome.app.window.open, it "downloads" the PDF, and then the user could open it. But this has two issues:
I can't realistically make the user go to chrome://plugins and do that disable
There isn't any browser window, so the user has no idea the download happened
Any suggestions? Opening PDFs that are embedded in my app is kind of a must-have feature for this app.
I've looked at this extensively, and have come to the conclusion that there's no way to get a Chrome App to open a PDF that's local. I, too, have tried data URIs.
I don't think the issue is the PDF support in the window, as it's still Chrome, or the size of the PDFs. Rather, I think it's just an engineering problem, one that might get solved someday.
As for me, I build the PDF in my Chrome App. Since I can't display it, and there's no server to upload it to, I write it to a file of the user's choosing and let the user deal with it on his/her own.
I've got this working, but whether it is a solution for you depends a lot on your use case. The solution has three parts:
Use pdfjs to do the actual rendering.
To get this running in a packaged app, you'd need to do some violence to the internationalization support. And even after you do that, you'll find that some PDFs refuse to load for no apparent reason whatsoever. So don't bother trying to make pdfjs work in a packaged app. Just:
Put your entire app into a <webview> with a persist partition, and use a HTML5 cache manifest to get all your files available for offline viewing.
Yeah, yeah, I know that cache manifests are not cool anymore. But if you can list all your files for use in a packaged app, then you are doing the one case where cache manifests actually work great.
Then use a packaged app to distribute a tiny wrapper around your page with the webview in it.
You'll also get the benefit that you don't have to rewrite your app to live within the draconian packaged app rules (eval, sync xhr, 2GB limit, etc.).
You can see a working example at m.kaon.com/c/ka (visit with Chrome to get the desktop app; if you visit that with Firefox, you'll get access to a hosted app that is using the same tricks). PDFs are down in the bottom "Why Choose Kaon" section.
I need to parse a local HTML file in the google chrome browser. I have read that a way of doing this, is to copy the HTML file into the SD card and load it. What I want to do is, open the HTML file in the chrome browser from the MyProject/assets folder.
I am currently loading the html through a url. Loading the html locally would make the page load faster. This is what I am doing right now.
Intent i = new Intent("android.intent.action.MAIN");
i.setComponent(ComponentName.unflattenFromString("com.android.chrome/com.android.chrome.Main"));
i.addCategory("android.intent.category.LAUNCHER");
i.setData(Uri.parse("http://www.example.com"));
startActivity(i);
What I want to do is something like this
Intent i = new Intent("android.intent.action.MAIN");
i.setComponent(ComponentName.unflattenFromString("com.android.chrome/com.android.chrome.Main"));
i.addCategory("android.intent.category.LAUNCHER");
i.setData(Uri.parse("MyProject/assets/htmlfile.html"));
startActivity(i);
First, get rid of the setComponent() call. Treat your users with respect, and allow them to use whatever browser they wish. Besides, Chrome is only on a small percentage of Android devices, meaning that your app will crash on most devices.
Second, get rid of the addCategory() call, and replace your Intent action with Intent.ACTION_VIEW.
All of that should be done regardless of where you are getting your Web content from, as your current approach is incorrect and unreliable.
With respect to assets, other apps cannot directly read your assets via a Uri. You can create a ContentProvider that serves your assets, but Chrome does not support the content:// Uri scheme. In fact, Chrome only supports http:// and https:// Uri values for loading arbitrary URLs -- it does not even seem to support file:// very well.
If you want to view an asset, display it in a WebView widget. There, you can use a file:///android_asset/ URL to reference one of your own app's assets.
I'm an iOS dev looking into some security aspects of a native iPhone app that loads local html pages into a UIWebView (that's the iOS class that give browsers functionality to a native app).
If the app loads a local html file and that file contains a link to an external html file then is it possible for that external file to download a file to the client (another html file or a javascript file)? My knowledge of html/javascript isn't detailed enough in this area.
E.g. If A.html is file physically present on the phone and A.html contains a href to B.html where B.html is on a server then is it possible for B.html (using whatever means) to move a file (C.html or D.js etc.) from the server onto the device?
What you probably mean is : are HTML pages able to download (and potentially execute or overwrite) content/code on the device? I'm just going to assume that in the following.
First, the browser isn't supposed to be able to download anything without the user consent. That's especially true on iOS, where the browser actually can't download anything at all. (Well, you can actually download images by long-pressing on them, but they are only going to go to the Photo Roll. Any other download will just fail.)
HTML pages (and JavaScript, images, ...) are of course downloaded to the device before the browser or UIWebView displays them, but they can't access anything on the filesystem.
What's more, due to the same-origin policy, a web page cannot access anything that's outside of its domain (cross-origin requests allow this, but they require the server to send a particular header).
Say your page is on http://mywebsite.com : you can't make a request to http://blah.org if it's not setup properly, or even (much more dangerous) to file:///etc/passwd (which you have no way to setup properly).
I'm not sure about local pages, but (at least on Chrome on the desktop) local web pages cannot download anything at all.
Of course, all of these are the expected behavior.
There have been cases of vulnerabilities (this one for instance) where Safari allows unprivileged access to the filesystem, but in most cases they have been patched quickly by Apple and you won't have to (and are not supposed to if you want to avoid unnecessary headaches) worry about them.
We have an "application" consisting of a large number of PDF files that link to each other.
Some of the PDF files have links that must be a web URL when running on a PC (or a Mac) but need to open a specific application when running on an iPad.
When not on the iPad, the links look like "http://10.85.1.102".
When on the iPad, they look like "netcam4://2" - which opens the NetCam4 application with camera 2 selected.
NOTE: this is already working but we have to create two versions of the PDF and it would be much better to have only one.
Is there a way using JavaScript (or ActionScript or whatever) for the PDF to determine in which OS it is being displayed and modify the link appropriately?
We don't care if this decision is made when loading the PDF or when the link is clicked.
By the way, so far we have found that GoodReader on the iPad is the only PDF viewer that will properly follow links - including those to the NetCam4 app.
Not really. PDF is generally run through a browser plugin and shouldn't have script running inside of it.
On the other hand, if you are serving these files up over http, you might be able to modify the contents of the PDF based on how they are compressed and what language you have on the server. PHP has PDFLib, for example, as well as Zend_PDF