cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse MacFadyen (JIRA)" <>
Subject [jira] [Updated] (CB-520) WP7 Certification and the Back Button
Date Wed, 02 May 2012 21:02:49 GMT


Jesse MacFadyen updated CB-520:

    Priority: Critical  (was: Minor)
> WP7 Certification and the Back Button
> -------------------------------------
>                 Key: CB-520
>                 URL:
>             Project: Apache Callback
>          Issue Type: Bug
>          Components: WP7
>    Affects Versions: 1.6.1
>         Environment: VS.NET 2010 and WP7.1 emulator
>            Reporter: Alan Neveu
>            Assignee: Jesse MacFadyen
>            Priority: Critical
>             Fix For: 1.8.0
> I tried submitting my PG 1.5 app to the Windows Marketplace and it was rejected due to
WP7's requirements for the Back Button. I upgraded to PG 1.6.1 and I am inspecting how it
works with the hardware back button.  It seems to work much better, but my app is designed
so that it has a soft back button in the app in various places, and on WP7 the user can always
tap the hardware back button.  I am trying to use and it appears
to work, but it does something slightly different than actually tapping the hardware back
button does.  I have also tried using window.history.back and that works different yet.  I
am using JQueryMobile 1.1.0 and so I wind up doing quite a lot of $.mobile.changePage calls
to #Page id's, and because I use multiple .html files I also need to do some rel="external"
links or window.location.href= calls.  I think my needs are similar or the same as those of
other WP7 developers.  Here is what currently happens with PG 1.6.1 in a simple Page1/Page2
JQueryMobile app when using the hardware back button versus using,
vs. window.history.back:
> SCENARIO #1 - using hardware BackButton only
> Page 1 links to Page 2 using $.mobile.changePage("#Page2");
> BackButton tap - goes back to Page1 but page is requested again and reloaded from scratch
which is slow and the user loses any form data they had entered.
> BackButton tap - exits app (great!)
> SCENARIO #2 - hardware BackButton and
> Page 1 links to Page 2 using $.mobile.changePage("#Page2");
>; goes back to Page1 served from cache, which is fast and
form data is preserved.
> BackButton tap: nothing happens
> BackButton tap: Page1 is reloaded from scratch
> BackButton tap: exits app
> SCENARIO #3 - hardware backButton and window.history.back
> Page 1 links to Page 2 using $.mobile.changePage("#Page2");
> window.history.back(); goes back to Page1 served from cache.
> BackButton tap: Page1 is reloaded from scratch (DOH!)
> BackButton tap: exits app
> My Observations:
> 1) The hardware back button does not use the cached page - it reloads/re-requests the
page. This is kind of a drag but I think we have to just go with this because it is the behavior
that the Marketplace testers will be expecting and validating.
> 2) window.history.back() is giving better results than, but
still not the same as the hardware back button. I think apps will fail Marketplace certification
if they use either of these approaches for soft back buttons.
> 3) When going back to an external page (as opposed to a JQueryMobile #pageID), window.history.back
works but does not seem to do anything at all.  I say window.history.back
"works" but it is still the same result as in Scenario #3 above, which is not good.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message