Hi Paul,
The page restoration error is more complex to handle. Page restoration occurs
with component actions (action bindings) that use the WO auto-magic context
restoration that make our job easier. This magic is based on the session
pageCache, if the request comes from a page no longer there, it fail with the
page restoration error.
Usually, I set the page ca size very low (2-5) so opening tab almost always
trigger this error when the user try to use the original one. You have some
choices to eliminate or reduce this error:
1- Raise the cache size in the application constructor with
setPageCacheSize(20); You specify the number of pages to keep. This will raise
the memory requirement of your app with all those page states and your user
will almost certainly always find a way to go over the limit.
2- Use direct actions links everywhere, they does not depends on page cache but
are a pain to use excepts for navigation.
3- Detect and prevent the use of multiple tabs or windows to inform the user of
the situation and handle it more gracefully.
Usually, I do not bother in internal apps, my users know the limit and I try to
implement all useful navigation in the UI. I developed a simple mechanism for
the third option that may works for you by adding this simple javascript on
each page (in your wrapper). This script will display an alert on the initial
tab when a new one load contents from the app. If user close the alert, the app
will redirect to the home page using a direct action. This will trigger the
display of the alert on the previous active tab for the app. Adjust the alert
text and direct action name for your app.
<script>
window.localStorage.setItem("replaceTab", Date.now());
addEventListener("storage", handleStorageEvent);
function handleStorageEvent(event) {
if ((event).key == 'replaceTab') {
removeEventListener("storage", handleStorageEvent);
alert('Vous avez une session dans un autre onglet.
Fermez cette alerte pour reprendre ici.');
document.location = '<wo:string value = "$reloadUrl"/>';
}
}
</script>
In the component class file:
reloadUrl = context().directActionURLForActionNamed("home", null);
You could probably create a better handling by replacing the alert with a call
to the server to save the current page context in the session and override
restorePageForContextID to restore it and clean the entry to reduce memory
leaks. If your users are connected for long period and use it often, your will
have leak for each closed tabs unless you handle this event to notify the
server to clean the context entry.
Regards,
Samuel
> Le 4 déc. 2025 à 17:14, Paul Hoadley <[email protected]> a écrit :
>
> Hi Samuel,
>
> On 4 Dec 2025, at 23:55, Samuel Pelletier <[email protected]> wrote:
>
>> Cookies are limited to a path, check the response headers of your app, you
>> should have something like this in direct connect:
>
> I don't think that's the issue here, I'm doing URL re-writing in deployment,
> but setting cookie "path=/".
>
>> Even with that, ,my app still create new sessions so I decided to dig
>> further. I did not bothered to check before but I noticed this behaviour
>> before. After my investigation, I found a secret override that control this
>> session creation. You simply need to override this method in your
>> Application class:
>>
>> @Override
>> public boolean shouldRestoreSessionOnCleanEntry(WORequest aRequest) {
>> return true;
>> }
>>
>> You may add logic, if the session if not found, a new one will be created.
>
> I can safely say that I've never seen that method before in my life...
> Thanks! So it turns out that one of my original observations was wrong:
>
>> I see in the new tab that the wosid cookie is not being sent on the first
>> request
>
>
> That's not true, I just wasn't seeing it. It does send the original tab's
> wosid, and with that method overridden does get the same wosid back in the
> response—a new session is not created.
>
> There is one remaining issue: on returning to the first tab, the first click
> on any link still generates a page restoration error, though the user's
> session remains, and then subsequent navigation is back to normal in both
> tabs. Any thoughts?
>
>
> --
> Paul Hoadley
> https://logicsquad.net/
> https://www.linkedin.com/company/logic-squad/
>
>
>
