How do I add fallback functions for history.pushState() and window.onpopstate ? I need an if..else kind of logic. If the browser supports proceed, else I need an alternative logic. Even in some modern browsers it is not supported eg. in iPad. If not pushState, I need way to catch the back button click of the browser in JS without any having infinite loop.
history.js might help you. It emulates html5 history functionality on older browsers.
https://github.com/browserstate/history.js
If you don't wan't to use history.js you can probably use url hashes and the hashchange event to catch the back button clicks.
Related
Please can somebody explain in more detail what $.mobile.hashListeningEnabled does when enabled/disabled in jQuery Mobile?
I have tried debugging the source, but there are some bits of code I do not fully understand. And the documentation is a bit abstract (https://api.jquerymobile.com/global-config/):
jQuery Mobile will automatically listen and handle changes to the location.hash. Disabling this will prevent jQuery Mobile from handling hash changes, which allows you to handle them yourself or use simple deep-links within a document that scroll to a particular id.
The reason I ask, is because I am having problems on iOS 9 with <select data-native-menu="false"> elements. If this list too long, jQuery Mobile creates a full-screen dialog.
But it closes straight after displaying. I have been looking around and noticed somebody else has the same problem: JQuery .popup("open") not working properly on iOS 9 device.
One answer suggested seems to work OK for me - which is to set hashListeningEnabled to false:
$(document).on('mobileinit', function () {
$.mobile.hashListeningEnabled = false;
});
But I am not comfortable rolling this out to production until I understand what exactly it does.
$.mobile.changePage seems to still function.
You can have multiple pages in one html file. And you can go to "another page" even if that page is actually another div with data-role="page" in it.
http://demos.jquerymobile.com/1.4.5/pages-multi-page/
So, if you are using this type of navigation, you are screwed.
Apple guess that somebody could make an XSS attack using hash.
/pages-multi-page/#two
popups are using hash also: /pages-multi-page/#&ui-state=dialog
I have a very simple test case that explains the problem.
Here's the page that I'm displaying in Rails in an ERB file.
<div><%=rand%></div>
<p>Go</p>
To show the error, I load the page. I note the random number displayed as rand1. I click on the Google link. I click the browser's "Back" button. I note the random number displayed as rand2.
Here's the problem:
In Firefox and Chrome, rand1 != rand2 (always).
In Safari and IE, rand1 == rand2 (always).
Why the discrepancy in browsers? Why is Safari and IE caching the output from Rails while the other two browsers are not? How do I get Safari and IE to refresh the page?
(This is a simple test case to show the problem - this has implications in my Backbone application).
IE and Safari appear to be caching the response from the server, obviously; as long as your browsers are configured correctly, you can change this by changing the Cache-Control header in the response.
Another Stack Overflow post shows the appropriate way to do that, though in Rails 3 there's a shortcut method to accomplish this: you can invoke expires_now in the controller action to avoid manually setting all these headers.
WebKit in particular has an aggressive page caching strategy for handling exactly the case you're describing (clicking a link and then immediately clicking the back button). The idea is to make the back action happen almost instantaneously by caching not just the resources but also the DOM and other state of the page. You can read about it in these two articles:
WebKit Page Cache I — The Basics
WebKit Page Cache II — The unload Event
You may be able to use a combination of the load/unload and pageshow/pagehide events to accomplish what you need.
I'm not sure if IE implements something similar to WebKit, but maybe this will fix it too.
When you click the browser back button on a site with jQuery Mobile, instead of leaving the page immediately the previous page is animated in. How is this achieved? I thought that their was no way to intercept the browser's back button (I can see why browser makers wouldn't want to allow this). Thanks
When using the hash URL scheme (no pushState plugin enabled):
Hash changes that occur independently of a click, such as when a user
clicks the back button, are handled through the hashchange event,
which is bound to the window object using Ben Alman's hashchange
special event plugin (included in jQuery Mobile). When a hash change
occurs (and also when the first page loads), the hashchange event
handler will send the location.hash to the $.mobile.changePage()
function, which in turn either loads or reveals the referenced page.
Source: http://jquerymobile.com/demos/1.1.0-rc.1/docs/pages/page-navmodel.html
When the pushState plugin is enabled the same goes but the hash is converted into a normal/readable URL:
There is an optional feature that converts the longer, hash-based URLs
mentioned in the previous section into the full document path which is
cleaner and makes the Ajax tracking transparent in the URL structure.
This is built as an enhancement on top of the hash-based URL system
for Ajax links. Note that despite the name, this feature technically
converts hash-based urls by using history.replaceState (not
history.pushState) in the current release because this works more
reliably across our target platforms. For browsers that do not support
history.replaceState, or if this feature is disabled, hash-based URLs
will be used instead.
Source: http://jquerymobile.com/demos/1.1.0-rc.1/docs/pages/page-navmodel.html
Also here are the MDN docs for the hashchange event: https://developer.mozilla.org/en/DOM/window.onhashchange
I've not written an iOS app and want to know if what I want to do is reasonably easy before I invest all my time in it. The idea is simply to leverage the built-in webkit methods to write my own browser. I've seen tutorials where this is done fairly easily. However, the twist is I want to apply some rewrite/regex rules prior to the page rendering. ie, you load http://example.com which is a page containing the word 'foo'. Prior to displaying the page, the app rewrites 'foo' to 'bar' and renders.
Is this possibly to do easily without actually writing a ground-up browser?
Thanks!
It's doable (assuming you're using the standard UIWebView component to render the page), and there are a few ways you could go about it. Among them:
You could download the HTML and parse it via Objective-C string handlers before loading it into the UIWebView
You coud use load the HTML as-is and use the UIWebview's stringByEvaluatingJavaScriptFromString: message to "inject" javascript onto the page, manipulating the DOM itself
You could go the Opera route, and pre-render the page via a server-side proxy before downloading it to the client.
How far down the rabbit hole you want to go would be up to you, of course. Easy is in the eye of the beholder.
I have a pager on a table using ajax and I would like each such request also to change the browser's url, so when I hit refresh button I won't skip back to first page. I was fighting the Url parameter of AjaxOptions, but it keeps winning over me. Please help.
Trim
You can safely change the URL past the hash mark without redirecting the page. However, the user can (in most browsers) navigate through these changes with the Back and Forwards buttons. This technique is usually called "history."
Because the technique is difficult to get working in all browsers, you'll want to use a framework. Take a look at http://www.mikage.to/jquery/jquery_history.html.
I can also recommend ExtJS's history stuff too. Take a look at this example:
http://www.extjs.com/deploy/dev/examples/history/history.html#main-tabs:tab2
Again, notice that not only does the URL change when the user does stuff, but changing the URL (via Back and Forward) also affects the page. This is good, awesome even, but means it must be done very carefully.
There is not really a quick and easy way to do this, here is an article on the topic. The problem is that not only does the Ajax have to generate the URLs, it also has to take those URLs into account when loading the page to get the appropriate content.