Just for good measure. All HTML5 inputs are now auto enhanced into the
styled versions. We may need to decide if any of these need to be
degraded if the controls are wonky in some browsers.
- Moved the settings.transition calculation code before the code that pushes a new history item on the stack. This ensures that the proper transition is stored with the history item.
- Fixed header/footer code now listens for a custom event "contentmodified" on the document to figure out if it should be repositioned or not. Modified collapsible and listview to fire off contentmodified whenever they modify content. Developers can also fire off this event to trigger position updates for fixed headers/footers, so this could be used to address issue #2042 and the mention of collapsible in #2596.
- Fixed a bug in the hashchange handler for the pushstate/replacestate plugin that was incorrectly resolving hashchanges for ids against the current location.href, which could be a different document. We now resolve id hashes against the document URL.
- Modified changePage() so that it sets the settings.dataUrl option to the documentUrl, when navigating to the first-page of the application document. This prevents any id on the first-page from being added to the location hash. This means that URLs that used to be produced like this:
http://site.com/apps/#first-page-id
will now display as:
http://site.com/apps/
Developers that wish to get the old behavior back can register a pagebeforechange handler and do something like this:
$( document ).bind( "pagebeforechange", function( e, data ) {
var toPage = data.toPage;
if ( typeof toPage === "object" && !data.options.dataUrl && toPage[ 0 ] === $.mobile.firstPage[ 0 ] && toPage[ 0 ].id ) {
data.options.dataUrl = "#" + toPage[ 0 ].id;
}
});
The handler above will make sure that any page changes to the first-page will always display as:
http://site.com/apps/#first-page-id
the frequency of the triggered event in certain android releases ( 2.1, 2.2) appears to be dependent on a host of things other than an actual orientation change, eg alerts, zoom, and scrolling. This provides a way for the user to disable it in favor for using throttled resize while still making use of the window.orientation where its available for reliability
The value attached to the event passed into handlers was based soley on screensize which is problematic given that some implementations (eg Android 2.3) don't change the screensize until after the event is fired. The orientation property appears to report a better value where it is provided so the solution is to prefer what it reports and then fallback to the screensize caculation where necessary.
- Modified loadPage() to call isFirstPage() with fileUrl instead of absUrl. Since fileUrl is the same as absUrl, but with the dialogHashKey stripped off, it will allow us to match against the url for the first-page.
- This was a regression from my fix to loadPage() for detecting un-enhanced pages by @id as a fallback. In this particular case dataUrl was being used to create an id selector, and of course if the dataUrl is an empty string we end up using "#" as the selector. The fix is to simply check for a non-empty dataUrl.
- Switch to using "click" instead of "vclick" on collapsible headers since that is the only reliable way to prevent uncaught/mismatched clicks from firing on a different element.
- Modified the pagehide callback in $.mobile._bindPageRemove() so that it fires off a "pageremove" event. Callbacks can prevent the removal of the page by simply calling preventDefault() on the pagremove event object that is passed to their callback.
- So it seems just allowing changePage() to process same toPage and fromPage is not enough. I modified the CSS3 keyframe
animation plugin so that it only removes the ui-page-active class from the fromPage if it is *NOT* the same as the toPage.
- I also re-ordered the in/out transition rules for forward/reverse transitions so that the user always views some sort of animation/motion.
- Added a new allowSamePageTransition option to the changePage() method default settings.
By default, we prevent changePage() requests when the fromPage and toPage are the same element, but folks that generate content manually/dynamically and reuse pages want to be able to transition to the same page. To allow
this, they will need to change the default value of allowSamePageTransition to true, *OR*, pass it in as an option when they manually call changePage().
It should be noted that our default transition animations assume that the formPage and toPage are different elements, so they may behave unexpectedly. It is up to the developer that turns on the allowSamePageTransitiona option
to either turn off transition animations, or make sure that an appropriate animation transition is used.
// To toggle the default behavior for all changePage() calls,
// set the default value of allowSamePageTransition to whatever
// you want it to be. The default is false.
$.mobile.changePage.defaults.allowSamePageTransition = true;
// To specify the behavior when manually calling changePage(),
// pass it as an option. If not specified, the default value
// specified by $.mobile.changepage.defaults.allowSamePageTransition
// is used.
$.mobile.changePage( "#reused-page", { allowSamePageTransition: true } );
- Added the following notifications to $.mobile.loadPage():
- pagebeforeload
- Triggered just before loadPage() attempts to dynamically load an external page.
- Developers can prevent the default loading behavior by calling preventDefault() on the event. If preventDefault() is called, it is up to the developer to call resolve()/reject() on the deferred object passed within the data object (2nd arg to the event callback).
- pageload
- Triggered after an external page has been loaded and inserted into the document.
- pageloadfailed
- Triggered when the load of an external page fails.
- Developers can prevent the default behavior (error dialog display) by calling preventDefault() on the event. If preventDefault() is called, it is up to the developer to call resolve()/reject() on the deferred object (2nd arg to the event callback).
scrolltop as a solution isn't that great but some browsers scroll to the top
of the page to where the element bearing the id matching the hash is located
*before* the hashchange event is fired meaning we don't have an opportunity
in the changepage event lifecycle to record the scrolling properly
- Modified loadPage() so that if the data-url lookup for a given page fails, that it look for the page via id (if it is an embedded page URL). This allows us to find dynamically injected pages that are un-enhanced and missing their data-url attributes.
Dialog not working if $.mobile.ajaxEnabled = false
https://github.com/jquery/jquery-mobile/issues/2451
related/dup bug 2202:
Dialog loads in new page with ajaxEnabled = false
https://github.com/jquery/jquery-mobile/issues/2202
- Modified the default click handler to check if the href is for an embedded page before bailing when ajaxEnabled = false. This allows us to navigate to internal/embedded pages/dialogs on the click versus waiting for the accidental hashchange that was the result of the browser's default handling of hash fragments.
- Modified the url parser regexp so that we can find the double slash that precedes the authority. This is necessary so we can reconstruct resource urls used on some devices like Rim's Playbook that use urls like:
location:/dir1/dir2/file.html
- Modified makeAbsoluteUrl() so that it uses the new doubleSlash property in the object returned from parseUrl() instead of assuming that it is ok to use a double slash.
Re-styled collapsible and collapsible set so the content of the collapsible now is applied the ui-btn-up-%%theme%% class. This way the border will match the border of the header button. In the meantime in the ui-collapsible-content class we remove the background image and tweak the margin/padding to make everything look good.
Combined the expand/collapse handlers into a single one and made extensive use of .toggleClass()
- Make sure that our hashchange resolves non-path hashes against the documentBase. This prevents the resulting changePath() call from incorrectly resolving against the URL for the current active (external) page.
- Fixed a problem in the push-state code. A hashchange event is *NOT* fired when navigating back (window.history.back()) from an external page to an internal page. This makes sense when you think about it since hashchange is only ever fired when the hash of the current document url changes, not when the document url itself changes. The fix was to make sure that the pushstate hashchange callback always sets a state object, even on embedded page URLs. This allows the hashchange callback to be triggered from within onPopState().
