If it is, register the callback as usual to fire when transition completes. If it isn't, simply defer the callback. This fixes a pernicious little bug where slowly cancelling a page turn in the Slider would "lock" the page -- you couldn't turn it again without a jump.
Firefox (recently?) does not pick up changes to href in the click event.
This fixes the problem of Firefox issuing requests for 'undefined', so we can close #75. There is a question about whether this is the right approach -- it's faster, but if tests modify the dom/styles of the test frame, things get unpredictable...
This is handy in a number of places, including search functionality.
Firstly, a bit more resilience against these views having weird UA strings. This has been tested in the Facebook iOS apps, where Monocle was breaking because it wasn't recognised as a WebKit browser. Secondly, UIWebKit apparently doesn't recognised the "about:blank" URL, so it was choking during the priming of frames. The little workaround is to direct UIWebKit frames to "blank.html" instead, which should just non-fatally 404 if there's nothing there. You could always put something there in this case. Refs #51.
I've always hated it. Now should only appear if the next page is actually taking a while to set (because it has a slight transition on the opacity, so near-zero setPage times shouldn't ever let the opacity reach 1). Need to test this on slower devices.
There's no point stacking the various style changes successively -- all of them will be applied on the next defer. So, just ensure there is a single defer before announcing the page change. Also, we can make the slide faster if there's been another slide very recently -- the user is obviously paging through the book quickly; let's not get in their way.
This one involves switching the order in which "onGoingBackward" works. Seems to have given a bit of a speed boost too.
If you are listening to these events, you need to update your code to listen to 'monocle:controlshow' and 'monocle:controlhide' instead. The 'evt.m' object is no longer the control object itself -- it's now an object with a 'control' property, whose value is the control object. This brings these two events into conformance with other Monocle custom events.
I think this fixes #57, but I haven't been able to completely reproduce it. See the test/events/index.html test in particular.
Clicking on the left half of the page now goes backwards; right half goes forwards. PageUp/PageDown are registered to backwards/forwards respectively.