pagecontainerbeforehide and pagecontainerbeforeshow data should contain both pages

[gabrielschulhof]

... otherwise, if you trap pagecontainerbeforeshow, you have no idea which page is being shown, because the event is triggered on the pagecontainer, not the page being shown.

Conversely, if you trap pagecontainerbeforehide, you have no idea which page is being hidden, because the event is triggered on the pagecontainer, not the page being hidden.

Currently (as of post-1.4.1), your only course of action is to listen to the deprecated pagebeforehide and pagebeforeshow events.

[gabrielschulhof]

The function that needs changing: https://github.com/jquery/jquery-mobile/blob/ecc9fa25d117d2cf85f99b5bf9cdcd3cfb01603d/js/widgets/pagecontainer.js#L751

[gabrielschulhof]

This will also fix events pagecontainershow and pagecontainerhide which will improve the fix for #7085, because in the handler defined in the demo at demos/toolbar-fixed-persistent/ we no longer have to grab the active page via $( ".ui-page-active" ), but we can grab it via ui.nextPage, where ui is the second parameter to the event handler.

[jtara]

It seems to me this is just a nicety, since (presumably?) you can rely on fetching the active page in these two instances. (And that would be the workaround for now...)

It certainly would be nice, though, for the parameters to be consistent.

Aside: The wordiness of working with the new events is painful. Most of us will wind-up either keeping a more terse variable around in our own JS, or simply letting events bubble up to $(document) or using $("html").) I guess this deserves a separate Issue. It is certainly painful and non-DRY the way the currently examples (where they exist and are consistent...) are written. I'd think it hard to rationalize to developers why they now are being told to use a long string of nonsense when they've lived in the land of milk-and-honey xxxxxxxx $.mobile.activePage(), $.mobile.ChangePage() etc. What was once clear and straight-forward is now a jaw-numbing finger-punishing tongue-twister...

I understand the reasons for the internal structure. But does it have to be exposed in (only) such a raw way to developers? There has to be a better way.

(I'll do a separate Issue on this wordiness issue after some thought, and checking for existing Issues. This has been really bugging me... It's a serious blocker to clarity.)

[gabrielschulhof]

@jtara, the widget factory allows you to attach event handlers via the constructor mechanism:

$( ":data('mobile-pagecontainer')" ).pagecontainer({
  beforeshow: function( event, ui ) {},
  beforehide: function( event, ui ) {},
  show: function( event, ui ) {},
  hide: function( event, ui ) {}
});

This way you can avoid some of the wordiness.

[SteveVaneeckhout]

It seems to me this is just a nicety, since (presumably?) you can rely on fetching the active page in these two instances. (And that would be the workaround for now...)

That is true for pagecontainerbeforeshow but not pagecontainerbeforehide.