For the file protocol, I'm informed that Chrome and its sycophants Chromium and Opera (COC) support neither cookies nor cross-frame file access.
To develop company documentation, I used cookies and cross-frame tables of contents with file:// using Netscape 3 and following. I continue so to use them for my own Web site, biblekjv.com/kjv-fm/startkjv.htm, both to develop that site and also to utilize it daily from my hard disk. Now I use Firefox for those purposes. Firefox and Internet Explorer handle them very well. The COC browsers do not. Why not? Ideally, for Web development and for off-line access to Internet pages, file:// and http:// should function identically. How do COC users develop Web sites? On the Google cloud? Please explain why emasculating file:// features is not a Google ploy to force us to use the Google Internet cloud instead of our own hard disks. Thank you.
Why don't just create a local web server on your machine. Also you could use localStorage.
Related
I'm pretty new in the field of Web Store and its content and I've been going through it for past few days. I am not sure if I'm getting it right, but as far as I know, Chrome Apps can be packaged or hosted and also I have noticed that both of them (packaged and hosted) will be removed from the Chrome Web Store on Windows, Mac and Linux.
But, according to this page, there are four types of content which can be published on Chrome Web Store - Websites, Chrome Apps, Extensions and Themes. And it somehow corresponds with the Web Store filters - you can filter between Websites and Chrome Apps.
And my question is - what is the difference between a Website and a hosted Chrome App? Is just Google messing up the terms (and by Website they mean hosted Chrome App and by Chrome App they mean packaged Chrome App) or is there any real difference?
Because this is what is totally confusing for me - in the early 2018, when all the Chrome App stuff will be removed from any other OS than Chrome OS, what am I going to see if I open the Web Store on Windows? Themes and Extensions only? Or the Websites will be available too, because only Chrome Apps will not be supported and a Website is not a Chrome App?
And after the "early 2018", is there going to be any way how to integrate a Website to Chrome other than telling the users to manually bookmark it? It won't be possible to distribute a web app through the Web Store at all? Because what I also noticed is Google encouraging developers to create PWAs rather than Chrome Apps, but how those PWAs can be integrated to Chrome more smoothly than just a manually added bookmark?
Thank you very much for your answers and sorry for a long and chaotic post full of questions.
Karolina
Gonna start by referencing the Wiki descriptions for a Website:
A website is a collection of related web pages, including multimedia content, typically identified with a common domain name, and published on at least one web server. A website may be accessible via a public Internet Protocol (IP) network, such as the Internet, or a private local area network (LAN), by referencing a uniform resource locator (URL) that identifies the site.
and a Google Chrome App:
A Google Chrome App is a web application that runs on the Google Chrome web browser. Chrome apps can be obtained from the Chrome Web Store where apps, extensions, and themes can be installed or bought. There are two types of apps, hosted and packaged, which have different locations of their executable and are targeted at different use cases.
and for Hosted Apps part:
Hosted apps are the original type of Chrome apps. They contain a single manifest file that contains the URL and additional information about the app. Hosted apps are usually offline and are subject to regular web page security restrictions.
To say things simpler, a Website is such a broad term where in some cases, a Hosted Web App might actually fall under it's category.
While a Chrome Web App has this required tie-in with Google Chrome (hence it's name).
For more descriptions on the difference between a Hosted and Packaged App (and an extension:
There are actually two kinds of apps: hosted and packaged. A hosted app wraps an online website, so the CRX package can be as simple as a single manifest.json file pointing to the website. A packaged app contains the whole kit and kaboodle inside the CRX package—HTML, CSS, and so on, all run from the user’s hard drive.
Packaged apps are a kind of missing link between extensions and hosted apps. They look the same as a hosted app to the user, but under the covers, they are really like traditional extensions with that special “launch” parameter. They have access to almost all functionality afforded to regular extensions—context menu, background pages, and so on. The only exception is that packaged apps can't add buttons to the address bar.
Returning to the example in the previous section, it’s perfectly valid for a packaged app to add an item to Google Chrome's context menu. However, it’s completely invalid for a hosted app to do the same thing. In some respects, a packaged app lets you have your cake and eat it: the appearance of a packaged app with the power of an extension. But there are still plenty of reasons to use pure extensions and hosted apps.
Guide for choosing an App Type can be seen here.
For the early 2018 part, there still isn't much details mentioned about it, but referring to the Chromium blog, I guess it's safe to say that the Chrome Web Apps will be totally removed (hence they're asking developers to migrate their Chrome apps to the web) and that only extensions and themes would be available.
However, this could still be subject for change. At this point, no one could really tell.
[...] there are four types of content which can
be published on Chrome Web Store - Websites, Chrome Apps, Extensions
and Themes.
I'd say that is accurate.
Some websites are just simple bookmarks you can find in the Chrome
Store. I consider these little more than advertisements.
Some websites do that and add trivial things like system
notifications and even run offline. I.e. they have their code on your hard drive and access some system resources. But Google still categorises them as websites (or webapps in modern vernacular) probably because they have no special feature set. An example is Spotify or Gmail offline.
Hosted Chrome apps might not have an online presence at all or typically do something different from the website version. For example, they could run in a specially designed transparent window; they may run offline too. An example is Hangouts, the app has slightly different features from the website at hangouts.google.com.
Packaged Chrome apps are defined similarly, but need more access to system resources such as the filesystem. They are pushing the border of what we may define as being 'sandboxed'. They also may run offline. In some cases people who want to write scripts using javascript and html/css may consider this instead of a nodejs-like solution.
what is the difference between a Website[/Webapp)] and a [...]Chrome
App?
Typically the ratio of 'fresh server code' to 'local drive code' gets smaller as you go down the above list, but this is just a correlation. The main difference between a Chrome app and a Web app is a unique content feature-set. Also webapps typically require at least periodic online contact, whereas a chrome app could just be a 100% offline game without an online counterpart.
Is just Google messing up the terms [...] or is there any real
difference?
So yes according to how I see it there is a difference. Though personally, I'd categorise everything that puts code on your local drive as a chrome app and stuff that runs at least 99.9% online as a webapp/website. But Google disagrees apparently.
in the early 2018, [...] what am I going to see if I open the Web
Store on Windows? Themes and Extensions only? Or the Websites will be
available too, because only Chrome Apps will not be supported and a
Website is not a Chrome App?
Only Google knows this I think. But I'm guessing you'll see Websites, and clicking "add to chrome" will create a bookmark for online stuff, or an extension for the offline stuff (like google docs). So you can distribute websites, you just won't be able to find them under an "Apps" panel. We'll also probably see an increase in extensions with a UI component as some apps are re-labelled as extensions.
I have been logged-in into stackoverflow in Chrome browser with my Google credentials and then I open stackoverflow in Firefox Developer Edition browser and tried to login again in Firefox with Google credentials. I have been automatically logged-in. I clicked to log out and after logout when try to login with Google credentials, I have been automatically logged-in again.
As per my knowledge, Firefox and Google chrome doesn't share the session.
So, I am curious to know whether this new FDE browser share session
with chrome or is it the feature of StackExchange?
No. Firefox/Chrome doesn't share sessions. Auto relogin is feature of Stackexchange. You can completely uninstall one of the browsers, clear cache and retry and this will still work.
Firefox/Chrome uses entirely different browser engines. Firefox based on Gecko and Chrome is based on Blink - each with it's own data storage formats. They may use sqlite, but Chrome still saves secure passwords with operating system security features like keystore in osx. Firefox saves password internally. Even if they wanted to, for data exchange both browser would need to arrive at a common data exchange formats with a LOT of security implications.
My team and I have just developed an offline portion of a web application utilizing HTML5, jquery and a cache manifest. The problem I am running into is when I disconnect from a wireless network, I am not able to view my offline site ( I receive a default screen from IE saying please connect to a network )?
I know that I have coded my offline cached site correctly because the site can be viewed when I disable my network adapter, just not a network adapter is on and not connected to a network?
Does anyone know if there is a way to bypass this default screen in IE when trying to view an offline site after disconnecting from a network?
Here is an offline page that was generated from our system:https://learn.questce.com/BranchAudit/OfflineSync/149/55/Michael-Kirk201372692619.html
IE9 does not support cache manifest. IE 10+ does, but it seems if you close the browser you can't re-open the site while offline (see my question here).
I did not get your question very clearly. But from what i understand, i will advice you to check out the offline browsing feature of internet explorer.
If you have already tried it and it is not working properly then you can try to run it in a browser named: "BackStreet Browser 3.2".
It is a high speed downloading browser and it is capable of downloading "HTML", "Java applets", "graphics" and many more features.
You can also view more details about this browser from: http://www.spadixbd.com/backstreet/
We have used HTML5s navigator.geolocation and found it to be very good on iOS and Android smartphones. Now the users want the same HTML5 web app to run on a laptop with external GPS. Using Windows 7 on the laptop I just can't figure a way to share the location to a HTML5 browser (tried Safari, FF, IE, Chrome). For testing I am using a GlobalStat BU-353 USB GPS which works standalone and I have found GPSDirect (cool freeware) to feed that signal to Win7 Sensor Location Services but still the HTML5 browsers do not see the GPS.
Anyone had any luck with this please ?
I was looking for similar solution and found this: GpsGate.
It is standalone application which connects to almost any GPS device and publishes it's data in several forms including browsers (through Javascript API which in turn makes jsonp call to http://localhost:12175/gps/[getVersion|getGpsInfo]?jsonp=padding). It's not compatible with Geolocation API, but I think writing simple adapter shouldn't take much time. Another good thing is that it's Express edition is free for both private and commercial use (link).
EDIT: After some digging I found this patch which adds geolocation compatible adapter for GpsGate to some other geolocation library.
Issue 45535 is beginning to address this in the Chromium feature requests. As of Jan 5 2012, the feature has been marked as "started".
Feature request: http://code.google.com/p/chromium/issues/detail?id=45535
As long as you only need a single browser for your client solution (and not a universal solution) this will solve your problem.
A great method to start testing and keeping an eye out for this issue is to download Chrome Canary, which is usually 2 versions ahead of the Chrome release. I'm right now using v18 on Canary and it's great since I've been keeping an eye on the websocket schema changes.
You can find Canary here: http://tools.google.com/dlpage/chromesxs
If Microsoft's method for using IE as a local host for HTA's then, can I use any other browser instead?
You can't.
There is a similar Mozilla project named XULRunner, but HTA only works in Internet Explorer - the two technologies aren't compatible.
To make this clear: HTA will probably not work in anything that's not IE. Yes, HTA is a browser control in a window, but it also has normal aplication privileges (i.e. filesystem access, registry, arbirary code execution etc.). When running in a browser, these privileges are denied (for good reasons - you don't want just any webpage to read your files).
So, launching the HTA in a browser will work, but any interaction with the local system will fail, which negates the whole idea. Launching a HTA in XULRunner will also fail, because XULRunner uses a completely different API.
The only scenario that could possibly work is this: a webapp which doesn't use any of the HTA-specific or XULRunner-specific API (i.e. behaves like a normal browser app). In such case, your app might work with HTA, XULRunner, as well as in any browser. Incidentally, this would take away any advantage of using HTA and introduce masive security holes because of the higher privileges; you'd be better off with using Google Chrome or Mozilla Prism for that.
(We've been trying to find a cross-browser solution for some time, and HTA is definitely not it)
I was tackling the related task of running hta's from various browsers. I've put my findings here for anybody else who is trying to do that and finds this question.
You can run hta's from several browsers, using the same mshta executable that IE uses. You need fully qualified URI's in your hta code, which isn't needed from IE.
Today (2011-02-01) I tried using hta's from Firefox (3.6.13), Opera 11 and Safari for Windows 5.0.3.
After some teething problems in Firefox I got hta's to work from those browsers. (In all cases these use the same mshta executable that IE uses. This is not hta's running in other browsers, but running hta's from other browsers. This might suit your purposes.)
The hta started desktop applications on my machine (as it does from IE).
The experience wasn't perfect. For IE I set root relative paths in the hta. For the other browsers you can't do that. You need to set fully qualified URI's for things like images, referenced hta's and icons.
So after a little editing I have the hta's working from 4 browsers (IE 8, FF 3, Opera 11 and Safari 5 (Windows)).
(Quick snapshot of that. I'm running hta's from a web server on the local machine. (I have no plans to run them from remote sites.) This allows my workflow to go from browser to desktop more smoothly. The hta's fire up local applications that do things like edit web pages (including the hta's themselves), validate those pages and fire up IDE's. Bridging the gap between browser and desktop apps. has been a liberating experience. I recommend it!)
Notes:
The Firefox development team have notes about enabling hta's which encouraged me to continue after initial failure.
To achieve this in Firefox configuration I set HTML applications to run under mshta.exe (called Microsoft HTML Application Host, in the combo box). Initially that didn't work. I selected "other" picked the same application by hand. That worked, though I have two identical looking entries! You need mshta.exe on your machine to run for any browser. I assume the normal way to install mshta is with IE. (mshta is essentially a modified version of IE, possibly not the current version!)
The Firefox developers have marked this as a strategic effort to dislodge IE from the Enterprise. Their implementation (and Opera's) force you to use fully qualified URI's but apart from that the hta's work as expected.
Firefox seems to cache old versions of the hta's, and doesn't download new ones, though it appears to download something! You might need to clear the cache during development.
My first attempt to do it with Chrome was not successful. Further investigation suggests Chrome doesn't have a native interface for invoking other processes, based on their file extension.
It isn't so much that IE hosts anything, but that mshta.exe hosts components it shares with IE. MSHTA is a script host, much as CScript and WScript are. While IE is also a script host (in the strictest sense) its primary purpose is to be a Web browser.
The Mozilla project mentioned previously is the closest alternative I have found that is based on a browser's innards.
Other script hosts exist for windows too. One of these is NS Basic/Desktop but it is based on standard Windows controls, not browser rendering and an HTML DOM.
Just to be clear: It is not IE nor MSHTMA that really renders a webpage. The rendering thing is partly build into the OS. Thus, things like Active Desktop (does anybody remember that XP thing?) or .HTA or .CHM work without IE. It's just the same way to recognise some HTML things.
I believe Internet Explorer's hosting of HTA apps works because their HTA host is registered to handle the extension. If this is indeed the case then in theroy another host could be used
For the sake of completeness I should note that I am not expeirienced in the development of HTA applications and am basing my response on my understanding of the Windows OS