How can I save history with AJAX just how github or google+ do. I use jQuery and I do not want to use some kind of hack like the # and #! tricks, because if I do, I'll need to change my whole project and make my life much more complicated?
Github and Google+ are using history.pushState.
You can change the current url like this:
history.pushState(null, null, '/the-new-url');
This is supported by Firefox, Chrome, Opera, Safari; not IE.
See https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history#The_pushState%28%29.c2.a0method
There are basically two options when it comes to AJAX and history.
The # method (which isn't a hack btw). Since you don't want that one you only have option 2 left.
Use PushState. This is what Facebook, GitHub and a few others use. It's not supported by all browsers though and if you want complete cross-browser compatibility you will have to use a system which can degrade to option 1.
A very simple way to implement this is Backbone.js Router class.
There is a simple jQuery hashchange plugin that is designed to solve this specific problem.
I haven't used it; I don't know how it keeps track of the url history.
Related
My latest website relies heavily on the new features of Bootstrap 4/CSS and is simply unusable on old browsers that don't support it which apparently some of my users are still using...
What would be the best way for me to detect when a user's browser doesn't support bootstrap 4 so that I can either redirect them or show them a different page? (it's the detection I need help with, not the redirection)
I've found some similar solutions for older/different frameworks but I haven't found anything that works specifically with bootstrap 4.
My stack is a simple JS, PHP7 and BS4 if that matters.
I've heard of Modernizr but I've never used it and I don't know if that could do what I need? What would be the detection code I'd need?
Worst case scenario, if I end up needing to rely on the UserAgent (which I know isn't reliable and a terrible solution), are there any prebuilt solutions available so that I don't need to reinvent the wheel and code the detection from scratch myself?
Thanks!
To detect the browser version I guess this answer can help you
[1]: https://stackoverflow.com/a/5918791/9350274
and you can redirect your users to a different page using a simple if else condition
If I go to a sub-path of a domain, the normal way is to do Some Path. This will reload the page completely.
But on Facebook, when you open a photo, the url on the address bar changes, however the entire page doesn't reload, it only loads the photo platform. So in this way people can share url of photos. I'm wondering how is this done?
I've done some search and some people suggested using history.pushState, however, this is only working on most modern browsers. The one on Facebook also works on IE 7, I'm wondering how they did it?
As you said, history.pushState is only available on modern browsers (noteably IE>=10).
For older browsers, the only way (as far as I'm aware) to change the URL in any way, was to use the "hashbang" technique - using/abusing the ability of hashs in URLs to retain page information. You'd then end up with a URL similar to index.php#!page=x&foo=bar where the hash would be used to represent the current page. The URL would then map one to one with a link such as index.php?page=x&foo=bar, and on refreshing the page, the JavaScript could read back the hash and display the page appropriately. It was by no means a great solution, in particular the browser doesn't correctly store your history, but it was still very popular.
If you're looking to use Ajax to reload pages and change the URL at the same time, then perhaps look into libraries such as History.js / Ajaxify, which will try to use pushState where available, but fall back to using hashbangs where it has to.
You seem to think that facebook supports Ajax for Legacy IE. I'm not aware of this as I can't say IE7 is very often my go-to browser, but IIRC Twitter has far less time for older, less feature-full browsers, and falls back to a much simplified interface (I think it even uses a basic mobile view). I'd probably take a similar stance if it was my website, and make use of pushState where available, and simply offer standalone pages where not. Working on backwards compatibility in these areas has the tendency to be fairly arduous (although the above-mentioned plugins will take quite a considerable load off), and unless you need to offer support, maybe it's just not worth it?
I do not know, how facebook did it, but if you look in the "routing" chapter of Backbone.JS you will see, that
For browsers which don't yet support the History API, the Router handles graceful fallback and transparent translation to the fragment version of the URL.
And if you look further, the sourcecode says:
// Backbone.History
// ----------------
// Handles cross-browser history management, based on either
// [pushState](http://diveintohtml5.info/history.html) and real URLs, or
// [onhashchange](https://developer.mozilla.org/en-US/docs/DOM/window.onhashchange)
// and URL fragments. If the browser supports neither (old IE, natch),
// falls back to polling.
This is the mentioned article to onhashchange.
That is probably the way to go.
When I use JSConsole and type window.history it dosen't contain any method for pushState. So what have happend? Is it removed in Android 4.0 in the default browser or how can I use it?
Yes, it is a regression bug, but they don't seem to be very interested in fixing it:
http://code.google.com/p/android/issues/detail?id=23979 vote for it.
Since most manufacturers usually customize the browser in one or another way, they might implement it themselves. I have however never came across any ICS phone which fully supports the history api. can't say I have been looking though.
EDIT: It has been claimed that it is fixed in 4.0.4, however only in the sense that the methods are there and do what you expect them to do, but the URL bar is not updated.
History API is well supported in Android 2.2 and 2.3, but versions 3 and 4 do not. There is no word on whether it will be put back in.
read more
But I think if you use chrome in Android 4 you can use this feature.
Background
Detection of hash change in the URL and fixing the forward/back button are two requirements for libraries that deal with Ajax history. There's two schools of thought for implementing these libraries. You can have a poller constantly check the URL (bad browsers don't have the onHashChange event). Or you can use a hidden iFrame to add points in your browser history. One may think the hidden iFrame is better than polling, but the hidden iFrame does not update the outer browser's URL. So if a user wanted to share her current state in the web application, she would always be sharing her initial state.
Question
Is there any technique for Ajax history that both doesn't require polling and also updates the main browser's URL?
How about a combination of the two techniques? change the url, as well as use the iframe. ignore hashChanged (on good browsers), and just parse the hash code on dom:ready
Looking at your comments from the original question, I would recommend using the iframes method for IE and polling for other browsers.
Check out Real Simple History if you are looking for a library that handles this specifically and you want a basis to help roll your own.
If you are just looking for the functionality of keeping your page's state in an Ajax UI, dojo supports this with the dojo.hash() shim. This method creates the onhashchange event for browsers that do not support it and manages the state of your back button. It uses a mix of polling and iframes depending on the browser (iFrames are used specifically in IE versions < 8).
I'm looking for a browser extension (Firefox, Chrome) allowing to replace a Javascript file on a live Web site to do some testing/hacking.
Basically, it should take a URL and load another one instead (locally or on a HTTP development server).
Any idea?
Try http://www.fiddler2.com/fiddler2/version.asp
It does that and much more. But it's not a browser extension.
I think this is a task for a personal proxy. You can sniff traffic on the proxy and apply rules to modify requests/content
The Opera browser has similar functionality:
View source code of the page (Ctrl+U).
Make some changes. Or paste and replace the entire file.
Press Apply Changes in the toolbar (Ctrl+R).
For editing linked resources (such as javascript or CSS files), use the following approach:
Open the linked resource in a new tab.
View "source code" of the resource (Ctrl+U).
Make some changes.
Press Apply Changes in the toolbar (Ctrl+R).
Return to the tab with the webpage and realod (Ctrl+R).
Alternatives:
Using chrome you can change code on the fly (Developer tools -> Sources tab) and just save it (command + s)
Use the LiveReload app that actually attaches an extension (that kind of does what you want) http://livereload.com/
This may not be the "exact" answer to your question, yet I almost sure one of those will do what you want to do.
Not sure if this helps or not, but I just encountered a chrome plugin called Resource Override, which sounds like it does something similar. Im trying out the Fiddler which someone else mentioned, but I think i'm also going to try this one at some point. https://chrome.google.com/webstore/detail/resource-override/pkoacgokdfckfpndoffpifphamojphii?hl=en
You can intercept and block requests in browsers. For example in Chrome you can use the beforeload event check if it's a JS (event.target is script tag or event.url ends in .js) call event.preventDefault() and then load your own script instead.
I'm pretty sure there's a similar way to do this in FF.
There is https everywhere which lets you define rules for url rewrites. This should work on all request, including script requests.
Tamper data might do the job, but I don't know how automated/permanent you can set it up.
And there is also an extension called redirector. I didn't test that one. Potentially it only works on the address bar.
Update:
That is unfortunate. In that case probably a proxy is you only way. What about a firefox extension that is a proxy, like Foxyproxy
ColBeseder correctly brings up Fiddler (http://www.fiddler2.com/fiddler2/version.asp) as a solution to your issue.
Fiddler is perfectly capable of handling and decrypting HTTPS traffic as well - see the documentation on the page for how to configure it.
To directly answer the OP question, you can use the autoresponder feature in Fiddler to hack your production JS for testing.
Enable the autoresponder tab in Fiddler, making sure to leave pass through for unmatched requests checked, entering the URL of the JS files you want to substitute as the pattern. Select the response file from your local filesystem, and go to town!
See http://yuiblog.com/blog/2008/06/27/fiddler/ (bottom of article is most relevant) for an example.
You should probably consider robohydra, since it is specifically developed for your case. They do not support https yet, but they are open to including it in the future.
Disclaimer: I'm the author of the software :-)
A different approach that might suit your usecase better is to use a RoboHydra-based development proxy. The idea here would be that you want to keep ALL Javascript files in your machine, and use another server simply as a backend. It's great for eg. front-end developers that don't want to have the whole backend installed in their machines.
You can see the documentation, tutorials and such at http://robohydra.org/, and have an article describing exactly that usecase at http://dev.opera.com/articles/view/robohydra-a-new-testing-tool-for-client-server-interactions/.
However, as of now it can't proxy to HTTPS URLs, but that should be a trivial change that I intend to do soon anyway.
How about Greasemonkey?
That should be the thing you're searching for!