As has been mentioned on many forums in many posts/questions related to cross-page posting, people want to know how to get server code on the source page to run before posting to the target page, i.e. how to have a button with the PostBackUrl property set and still fire the handler for the OnClick event. One reason to want this is if there is some processing (calculation, database, etc.) required by the source page to determine value(s) required for the target page. The proper response is to clear the PostBackUrl property and perform a Server.Transfer([Target]) after the required processing in the OnClick event handler. One downside, perceivably, to this is that the URL displayed with the target page is still that of the source page. A Response.Redirect will avoid this issue but will leave the Page.PreviousPage property of the Target as null removing any benefit of first performing calculations on the Source as this communication channel is now inaccessible.
Here is some curious behavior that might be useful to be aware of. If the PostBackUrl property is set and there is an OnClick event handler, the OnClick event handler does not fire directly as the Source is posting directly to the Target. However, if the Target, in the Page_Load, examines the Page.PreviousPage property something interesting happens. At the point the Page.PreviousPage is evaluated flow shifts back to the Source starting with the Page_Load followed by the OnClick event handler in the same way it would have progressed if the Source had posted back to itself. It seems to continue with the standard lifecycle moving through the Page_Load of the MasterPage which has some interesting implications discussed further below. After the Source completes its lifecycle, flow then returns the Target at the point following where the PreviousPage was evaluated. So, if one needs to do additional processing on the Source to make data available to the Target it seems that this can be done in the OnClick event handler of a button that also has the PostBackUrl property set as long as the Target does not try to consume the information before referencing its Page.PreviousPage property. I don’t know that this approach would be considered best practice as the behavior seems kind of quirky.
On a related note, as mentioned above it seems that when the PreviousPage is referenced it causes the Source to go through its complete lifecycle including that of its MasterPage. If the Source/MasterPage are heavy during load, e.g. lots of validation, initialization or database transactions, it may be beneficial to wrap these processes in an if(){} block evaluating that Page.AppRelativeVirtualPath == Page.Request.AppRelativeCurrentExecutionPath. That is to say, the page that is currently running is that same page that kicked things off.