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.
Related
Description
Is it possible to modify or override the perceived current location and origin in Electron.js?
I am loading a local .html file in Electron, and I need to manually override location.href, document.domain, and all other references to the current location to point to https://example.com/my/page in order for some external libraries (e.g. reCAPTCHA) to work with the local page.
Is it possible to set the current location to be example.com, without actually making a request to the remote URL, so that any javascript on the page thinks that the current URL is that, instead of app://....?
What I've tried
For my tests, I achieved it by running a MITM proxy that intercepts HTTPS requests, and instead of making a request to the origin, responds with a locally generated html page, which therefore I can inject my actual content into.
However, I don't want to go with this approach, and I was wondering if Electron could natively masquerade as a custom URL while loading local files, and report to any content un the page with the appropriate location/origin.
I have an HTML based project that works with media from other websites, which embeds images / songs / videos using their direct links. The system works perfectly so far, but I wish to make a change: As a lot of assets are accessed repeatedly by viewers, it would seem more optimal to cache them in a controlled way, so whenever certain media pops up you don't need to fetch it from the origin server each time. I never did this before so I don't know if and how it can be done.
To use an oversimplification: I have an embedded photo called "image.png" inside an image element, which will show up whenever I open the site. Currently it's simply defined as:
<img scr="https://foo.bar/image.png">
Works perfectly! However I want to make sure that when my site is accessed, you don't need to fetch that image from foo.bar each time: You will keep it in a local directory after downloading it once, from which the script can fetch and work with the file independently. For Firefox for instance, this subdirectory would be inside your ~/.mozilla/firefox/my_profile directory. Ideally it can be defined using a fixed name, so no matter which URL the website is opened from it uses the same cache path instead of each mirror of the project generating its own.
First, my script must tell the browser to download https://foo.bar/image.png and store it into this cache subdirectory. After that, it would need to generate a link to embed it directly from that subdirectory, so the URL I use would now be something of the following form:
<img scr="file://path_to_cache/image.png">
How do I do those two things, in a way that's compatible across popular web browsers? As a bonus, it would be useful to know if I can limit the size of this cache directory, so once it reaches say 100 MB the oldest items will be removed to stay under that size.
You could alternately add caching to your server's .htaccess file.
This site explains how: https://www.siteground.com/kb/leverage-browser-caching/
However this does not cache the image on the user's machine, it is cached on the server for quicker response.
You could use service workers to cache images on the user's machine.
https://developers.google.com/web/ilt/pwa/lab-caching-files-with-service-worker
Hope this helps.
I have a PhoneGap application in which I need to download certain images for offline usage and show those inside an iframe. Is this possible and do I need something like CorHTTPD (https://github.com/floatinghotpot/cordova-httpd) to serve the assets locally?
I have been trying to store the files on file system but when I try to show those (even without being inside iframe), those doesn't show. They seem to be loaded (can be seen in network console in remote debugging), though, but (of course) without any headers.
After spending more and more time on this and settings GapDebug correctly to remote debug my application, I was finally able to solve my problem by giving
{responseType: "arraybuffer"}
to AngularJS's $http.get method as config parameter as described here. Now I am able to get the images to ArrayBuffer correctly and from there to base64 encode them to be added inside HTML stored offline. Suitable solution for my case at least..
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.
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.