From the documentation of $location
Fallback for legacy browsers For browsers that support the HTML5
history API, $location uses the HTML5 history API to write path and
search. If the history API is not supported by a browser, $location
supplies a Hasbang URL. This frees you from having to worry about
whether the browser viewing your app supports the history API or not;
the $location service makes this transparent to you.
It works fine under FF,Chrome and IE10 (whatever the browser mode). However when I try to test in less than IE9 mode, the fallback mode with hashbang behaves oddly. The window location is converted as expected
http://myserver.net/#!/thewebapp
it displays the server root content since angularjs fails during the rendering.
SCRIPT5022: 10 $digest() iterations reached. Aborting!
After reading other Q/A, I suspect IE10 can't be used this way. Another source is maybe the server side rewriting or a combination of both. Right now I have no clue.
Related
CanIUse and MDN doesn;t seems to be agree on the support for service worker. In the midst of Chrome going to remove support for appcach, we are trying to ascertain the impact of moving to Service Worker. Are we reading the above two pages incorrectly?
We tried Google's own samples against device/browser combinations and results wore not encouraging. For example the 'custom offline page' demo failed in iOS Chrome (v80) where it worked in iOS Safari (12.4.5).
The 'Selective caching' and 'Read through caching' pages clearly show "service worker is not supported in the current browser" in Chrome 80. It is checking the if ('serviceWorker' in navigator) {, but other samples doesn't show such a message.
All and all it is confusing on the browser support for the Service worker. Is there there a universally tested sample which we can use as a benchmark for different device/browser combination.
I asked Jake Archibald of Google on this and he replied with the following SO post which must be still valid.
Chrome Service Worker iOS Support
Therefore apparently Safari is the only option at the moment. I am still wondering what Google is recommending developers to use once they remove support for AppCache.
Jake continued saying there is no way they can add support as Apple is not giving them full rights on iOS. But he mentioned appcache will continue to work as usual. His exact words are
"However, since Chrome on iOS is just a skin over Safari, appcache will continue to work while it works in Safari webview."
on iOS only Safari supports service workers. You can test browsers if it supports with this code
if ('serviceWorker' in navigator) { /*supported*/ }
I've read that Firefox has begun supporting a cache control extension value of immutable, which means that "the response body will not change over time." So even if a user requests a "full refresh" of a page or resource, the browser still only responds with the locally cached copy, thus avoiding unnecessary 304s or page refreshes, and making pages load faster since cached content is used, and decreasing load on servers, since a large number of requests are stopped before they even happen.
I'm trying to see how well this is supported, and am finding varying answers, as this mozilla page suggests that it's only supported in Firefox, but this resolved Chrome issue suggests it's been available since Chrome v54.
Which browsers support Cache-Control: immutable, and when did they start supporting it?
I first read about it here on this Hacker News discussion
Here's an ietf draft on it, the original mozilla post announcing this beta feature being used by Facebook and this related mozilla post, and a document discussing the different types of reloading requests from some Google chrome devs, it appears.
As of February 2017, Cache-Control: immutable is supported by
Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=1267474) since Firefox 49
Chrome (https://bugs.chromium.org/p/chromium/issues/detail?id=611416) since Chrome 54 They aren't implementing this.
Safari (https://bugs.webkit.org/show_bug.cgi?id=167497) in Safari Technology Preview 24.
It is also listed on MDN and Can I Use ... ?.
As of April 2017 it is also supported in "classic" Edge
I am making an app which will support the "Add to Homescreen" features in Android Chrome and iOS Safari. Since I would like universal offline support for both of these features, but I only want to use the manifest file where I have to, in order increase my control. However, iOS Safari does not support service workers, so my question is how can I only instantiate a cache manifest file if support for Service Workers is not present, more specifically; I know I could add manifest='whatever.appcache' to the <html> tag with JavaScript, but will browsers, specifically iOS Safari, use that cache?
According to an answer by #Daniel Herr:
You could choose to use Service Workers and AppCache on the same web app. What happens in such a case is that browsers that don’t support Service Workers will use AppCache, and those that do will ignore the AppCache and let the Service Worker take over.
Sources: https://www.w3.org/TR/service-workers/#activation-algorithm, https://crbug.com/410665
Thanks for your answer!
Hi I am creating an angularjs app . I made $locationProvider.html5Mode as true. Now I am getting pretty url without # . It is working fine in chrome and firefox. But when I tried to open it in IE 9 , it is reloading continuously.
Bad news. IE9 do not support HTML5 History API. That is what angular html5Mode uses. If you need your app to run on IE9 you need to switch back or add code to detect if History API is available the use is or default to the hash
function supports_history_api() {
return !!(window.history && history.pushState);
}
I know. Stupid IE. It should die a painful dead.
$location Documentation
See "Hashband and HTML5 modes"
Basically, html5 mode uses History API when the browser supports it, and falls back to hashbang(#) when it is not supported.
You cannot "just" remove "#" in a browser without History API. Because when you change the url, the browser would then try to force a reload, breaking the flow.
Is anyone aware of whether it is problematic to use protocol relative URLs for an image source to prevent mixed content security warnings.
For example linking an image like:
<img src="//domain.com/img.jpg" />
instead of:
<img src="http://domain.com/img.jpg" />
or
<img src="https//domain.com/img.jpg" />
In my testing i've not seen anything to suggest this is wrong but i'm not sure if it has edge cases where it will create problems.
EDIT i've seen it throw errors when using PHP's getimagesize function.
Found an interesting gotcha for the use of protocol relative URLs:
You have to be careful to only use
this syntax in pages destined for
browsers. If you put it in an email,
there will be no base page URL to use
in resolving the relative URL. In
Outlook at least, this URL will be
interpreted as a Windows network file,
not what you intended.
from here
Essentially though there are no valid reasons why this shouldn't work as long as the request is made by a browser and not an external email client.
more info from here:
A relative URL without a scheme (http:
or https:) is valid, per RTF 3986:
Section 4.2. If a client chokes on it,
then it's the client's fault because
they're not complying with the URI
syntax specified in the RFC.
Your example is valid and should work.
I've used that relative URL method
myself on heavily trafficked sites and
have had zero complaints. Also, we
test our sites in Firefox, Safari,
IE6, IE7 and Opera. These browsers all
understand that URL format
IE 7 and IE 8 will download stylesheets twice if you're using a protocol-relative URL. That won't affect you if you only use it "for an image source", but just in case.
The following should be considered when using Protocol-Relative URLs:
1) All modern browsers support this feature.
2) We have to be sure that the requested resource is accessible over both HTTP and HTTPS. If HTTP redirects to HTTPS it is fine, but here the load time will take a little longer than if the request was made directly to the HTTPS.
3) Internet Explorer 6 does not support this feature.
4) Internet Explorer 7 and 8 support the feature, but they will download a stylesheet twice if protocol-relative URLs are used for the css files.