In the $.ajax() callback, we look for elements with @href, @src, and @data-ajax="false" elements, the code then assumes that matching elements will have either @href or @src, which of course forms don't ... they have @action ... so the code throws an exception because thisUrl is undefined.
- I reworked the code to handle action and check to make sure we have an attribute and url string before attempting to use them.
This was caused by this checkin:
4b4ee54a72
The change caused the base tag to be reset to file:// (literally with no path).
All that was missing was a small tweak to base.reset() to use the new initialPath variable instead of docBase.
Remove greedy matches from start and end of regex - there's no need for them, and they cause immense slowdown (on the order of 3-4 seconds on medium-size pages loaded via ajax).
* whitespace within parenthesis
* double quotes
* line breaking for object key assignments
Also made several changes suggested by jsHint.
All tests pass as before -- still failing first three tests as before.
Signed-off-by: Steven Black <steveb@stevenblack.com>
The expected prototype for a transitionHandler is as follows:
function handler(name, reverse, $to, $from)
The name parameter is the name of the transition as specified by @data-transition attribute, reverse is a boolean that is false for a normal transition, and true for a reverse transition. The $to param is a jQuery collection containing the page that is being transitioned "to", and $from is an optional collection that tells us what page we are transitioning "from". Because $from is optional, handler developers should take care and check $from to make sure it is not undefined before attempting to dereference it.
In addition to registering custom transition by name, developers can specify a handler to use in the case where a transition name is specified and does not exist within the $.mobile.transitionHanlders dictionary. Within jQuery Mobile, the default handler for unknown transition types is the $.mobile.css3Transition() handler. This handler always assumes that the transition name is to be used as a CSS class to be placed on the $to and $from elements. To change the default handler, simply set $.mobile.defaultTransitionHandler to you function handler:
$.mobile.defaultTransitionHandler = myTransitionHandler;
The changes to make all this necessary are as follows:
- Created $.mobile.noneTransitionHandler which is the default transitionHandler for the framework that simply adds and removes the page active class on the $from and $to pages with no animations.
- Moved class based transition code into a new plugin jquery.mobile.transition.js file. This plugin, when present, overrides the noneTransitionHandler as the defaultTranstionHandler for the framework so that CSS3 animation transitions are available.
- Removed code related to the setting/removal of the ui-mobile-viewport-perspective class. The css3TransitionHandler plugin takes care of automatically placing a "viewport-<transition name>" class on the viewport (body) element. This allows any other transition to specify properties on the viewport that are necessary to accomplish the transition.
- changed the CSS class ui-mobile-viewport-perspective to viewport-flip to match code changes. This makes it more apparent that setting -webkit-perspective is only used with the flip transition.
- Updated js/index.php, Makefile and build.xml to include the new jquery.mobile.transition.js file.
Removed the return false in the vclick handler of collapsible and replaced it with a preventDefault(). The only reason we were returning false was to stopPropagation() so that the vclick handler in navigation.js didn't place a ui-btn-active on it.
- Modified vmouse code so that it uses $.data() instead of $().data() which is significantly faster.
- Modified the navigation and buttonMarkup code so they stop using live(). The vmouse code triggers several events during the touch events, which in turn causes the underlying event code to call $.closest() with the selector used during the live() call to figure out if the event should be handled. This turns out to be very expensive, so instead, we now just bind directly to the document, and walk the DOM manually to figure out if we should handle it. This is much faster since we are avoid triggering multiple nested function calls.
- set active state on all button vclick events
- cancelled vclick on slider switch handles so it's not too sticky.
- removed addClass in navigation.js as the first change handles it there.
- Third party click handlers never called.
- Touch and click target mismatches due markup changes before the click events are generated. (What looks like a double click event)
For vclicks dispatched via touchend, calling preventDefault causes mouse clicks to be suppressed. This is why the 3rd party onclick handlers weren't getting triggered. For vclicks dispatched by a real mouse click this isn't a problem.
The fix basically removes the preventDefault() call from the live("vclick") handler and places it in a real live("click") handler. This allows the mouse event to get dispatched and trigger 3rd party click handlers, and still call preventDefault to prevent the link from being followed.
