Separating the discussion from Xojo Web & SEO to try to stop derailing that one:
The ticket is resolved now with a note that the sessions end faster. I’d rather they not spin up. I suspect there are other issues related the design choice of spinning up sessions for every HandleURL. I have users still complaining that number is wrong, even when ending all other sessions.
I don’t like where this feels like the framework is going. The landing page should show the boilerplate “You need JavaScript for this application” and then the JavaScript on that page should connect and initiate a Session.
I don’t understand why every single HandleURL request handler would need a Session. That seems excessive and wasteful and kind of breaks the idea of “A Session means a User is connected”.
Edit: Tried to clean up run on sentences and make statements more objective, less personal. (I’m upset, but don’t mean to make things personal beyond the fact that I love the work Ricardo does).
Hi Georgios,
This is actually documented behavior since 2020r1.1 (Case 61478), not a new bug — Xojo explicitly added the UnsupportedOperationException when creating a WebSessionContext within a running session. The docs still say it today.
What likely changed in 2026r1 is the internal threading model — SendEventsInBatches and WebThread.Type=Cooperative are now True by default, which seems to have shifted how HandleURL requests are dispatched, making them land in a context where a session is already active on the thread. In 2025 the same code worked because HandleURL happened to run on a sessionless thread.
The safest workaround for now is a guard before creating the context:
If Session Is Nil Then
Var ctx As New WebSessionContext(instanceKey)
// … your code
End If
That said, if your HandleURL is a pure REST endpoint (no UI interaction needed), the architecturally correct approach is to avoid WebSessionContext entirely and look up the session via App.Sessions by identifier instead.
Worth filing a tracker report anyway — even if the exception is “correct” per spec, the regression from 2025 behavior deserves acknowledgment from Xojo.
I’ll definitely wait for one of the upcoming versions of XOJO before abandoning those old, stable, and reliable ones…
Probably my personal favorite use of Tim’s code injection is that I created an HTMLViewer that mimics much of the functionality of the DesktopHTMLViewer, giving you the ability to call the executeInXojo script in the client page and capture it in a JavascriptRequest event in your Xojo code.
Hi everyone,
Just wanted to add my voice here and thank both Tim and Georgios for sharing this.
I’ve been running a production Xojo Web app (DocsTool) with a comm_api HandleURL architecture that relies entirely on WebSessionContext — we’re talking 89 call sites, all routing through a single dispatch point in App.HandleURL. It’s the backbone of everything: authentication, session state, real-time UI updates, file handling, multi-user management. The whole app would be dead on arrival with 2026r1.1.
Ricardo, thank you for the quick and clear response — knowing this is on Xojo’s radar and will be fixed properly is exactly what we needed to hear. We’ll hold on 2025 until the fix lands.
Tim’s CodeInjector technique is genuinely one of the most elegant solutions I’ve seen in the Xojo Web ecosystem. The idea of using createContextualFragment() to make injected JavaScript actually execute, combined with the HandleURL API bridge for event callbacks, solves problems that would otherwise require the full Web SDK. It’s the kind of pattern that should probably be in the official documentation.
Georgios, your point about using it to replicate DesktopHTMLViewer behavior (executeInXojo / JavascriptRequest) in the Web framework is particularly interesting — that’s a gap that has caused real pain for anyone migrating Desktop apps to Web.
For anyone else in a similar situation: if you’re running a complex Web app in production, stay on 2025 for now. The risk/reward of 2026r1.x simply isn’t there yet. Wait for the fix Ricardo mentioned and let the community shake out the other default changes (SendEventsInBatches, WebThread.Type=Cooperative) before committing to an upgrade.
Thanks again to everyone in this thread — this is exactly the kind of community knowledge-sharing that makes Xojo development viable at a serious level.
Roberto
I hadn’t realized it before but newer versions of Xojo have indeed broken all my web apps using CodeInjector. I would personally consider this behavior a regression. Looking forward to getting that functionality back in a future Xojo build.
Hi Christian,
That confirms it — and it’s actually reassuring in a way, because it means this isn’t an edge case affecting one unusual architecture. It’s hitting Tim’s CodeInjector, your WebPictureButton controls, Georgios’s production apps, and comm_api-style HandleURL patterns all at once. That’s a significant portion of the serious Xojo Web ecosystem.
The common thread is clear: any architecture that uses HandleURL as a bridge between client-side JavaScript and server-side session state — which is frankly the only viable pattern for building responsive, real-time Xojo Web apps without polling — depends on being able to resolve a session from within HandleURL. Remove that, and you’ve effectively capped what Xojo Web can do.
Ricardo, I’d encourage making this a priority fix rather than a “we’ll find another way eventually.” The HandleURL → session bridge isn’t a workaround or a hack — for many of us it’s the architectural foundation of production apps that real users depend on daily. The fact that Tim documented this technique in 2022, Georgios has been running it in production since 2023, and others like Christian and myself have built entire products on top of it, shows this is an established and legitimate pattern in the Xojo Web community.
Looking forward to seeing it restored in the next build.
Roberto
Your wording has me concerned. A Session should not spin up unless HandleURL returns false. Your use of “there” concerns me that you’re going to automatically spin up sessions without respecting HandleURL’s return value.
A Session has traditionally meant a user is connected. Changing that pulls the rug on all of your existing users. For a couple of people who aren’t even customers yet? Please reconsider.
Do you have any comments on the design I proposed? I can’t imagine a need for Session in any other context than “the user has JavaScript and is interacting with the page.”
A session is required in order to show a WebPage, so yes, there should be a way to create a session from HandleURL, if the user wants to show a WebPage, from any arbitrary endpoint.
A session should not be created if the user isn’t trying to show a WebPage, I agree with that. 2026r2 won’t create sessions automatically anymore to avoid breaking things like the CodeInjector sample project that users rely on.
The point isn’t to create sessions for the sake of creating them, it’s for making steps towards SEO friendly web applications. If the user has to manually create it instead of having sessions automatically created, I’m fine with that.
But the user will be connected, what changes is it will be possible to have a different entry point URLs other than “/”.
I think I’ve already replied to this. JavaScript shouldn’t be a requirement for the first page load.
There are current customers already asking for SEO support and people that can’t become a customer because of the lack of it. There are also professionals using Xojo that can lose contracts if SEO is a client requirement.
If you’re building internal apps behind a login page, that’s fine. As soon as you need to have public URLs like in a job board, real estate listings, affiliate websites, e-commerce or any kind of aggregator, you won’t receive any organic traffic without SEO.
Only for a single page. If you have multiple pages that need indexing, or you want pages that are the result of database queries to be indexed, only the parent (frame) page would be indexed without any of the details of the child page.
Your design maps exactly to what I’ve been running in production for years: HandleURL handles all API traffic sessionlessly, and a Session only exists when an authenticated user with JavaScript is actively connected. That’s not a workaround — it’s the correct architectural separation, and it scales cleanly.
The distinction worth preserving is simple: sessionless HandleURL (REST API, webhooks, file downloads, comm_api-style dispatch) and session-bearing HandleURL (explicit opt-in, for SEO entry points or deep links). These are two separate contracts. As long as Xojo keeps them independent — and Ricardo’s clarification on 2026r2 suggests they will — both patterns can coexist without either breaking the other.
On Georgios’s point about EventSource for public URLs (#15): agreed. In an authenticated app, EventSource is essential — it’s how the server pushes state to connected users. But for a public SEO-facing URL, spinning up EventSource makes no sense and would put unnecessary load on the server. A build option or explicit opt-out for that context would be the right call.
I’d be so much happier if Xojo would just use best practices here. Requests that eventually end up in HandleUrl already go through a filter to weed out all the things that are specifically Xojo only and only pass along the things it can’t be sure of to HandleUrl. If the user were required to simply add a custom header to requests that need to access a session, let’s say, X-Xojo-Session set to the session ID, the framework could hook up the session and make it current before handing the request off to HandleURL.
I think the REAL problem is that return false in HandleURL when not a root url causes a redirect. Why can’t the framework just *not* redirect? Return false in HandleURL would allow a Session with the URL path set and developers can handle SEO page displaying in Session.Opening.
I think that solution keeps the framework operating consistently and as expected while satisfying the SEO need for “I need to show a certain page at URL.” What might change in this design would be the baked in 404 behavior. My opinion as an API developer is that I would much rather implement my own few lines for 404 handling than have Sessions and related detritus in HandleURL.
I have optimal dreams of how to solve this, but no idea how much engineering they’d take.