If you open a second tab, using cookies, they are shared. If you continue doing more than 30 actions or so in the second tab, and then later try to do 1 action in the first tab, it will break. The first tab will try to do something but the page is out of the backtrack cache already.
Last tab wins. > On Aug 21, 2024, at 6:55 AM, OCsite <o...@ocs.cz> wrote: > > Aaron, > >> On 21. 8. 2024, at 1:16, Aaron Rosenzweig <aa...@chatnbike.com> wrote: >> Sounds like maybe your session is in the URL? > > Nope, we store them in cookies. > >> What if you put the session in a cookie? Then it’s not possible to have >> multiple tabs in the same browser. The last tab wins. > > Alas, that's not how the browser works. Pretty often, e.g., if one opens a > link by shift-cmd-click in a new tab, and in other cases too, more > tabs/windows simply share the same wosid cookie, i.e., the same session. > > Myself I use Safari exclusively, but based on > https://stackoverflow.com/questions/49687204/same-browser-but-different-windows-do-they-share-cookies > > <https://stackoverflow.com/questions/49687204/same-browser-but-different-windows-do-they-share-cookies> > it seems it is a customary behaviour in other browsers, too. > > Thanks, > OC > >> >>> On Aug 19, 2024, at 9:25 AM, ocs--- via Webobjects-dev >>> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >>> wrote: >>> >>> Hi there, >>> >>> looks like the main cause of those overlapping R/Rs which we ar clashing >>> with lately is that some users just open their session in more windows or >>> tabs, and work concurrently in those. Sigh. >>> >>> It's self-evident why it is a pretty bad idea from the technical POV, but I >>> am afraid we can't explain it to plain users. Worse, if we found a way to >>> prevent that (offhand, I am not sure whether it is technically possible, >>> but even if so), I am afraid the users would complain that they simply >>> insist on this terrible approach. >>> >>> Now though they complain some operations are “inexplicably” slow: “I >>> understand that operation A which I've launched in one of my windows is >>> complicated and thus takes many seconds, that's OK. But at the same moment >>> I've launched an operation B in another of my windows; operation B is >>> trivial and should be lightning fast, but it took an eternity! Fix your >>> broken application!“ >>> >>> Well you twit, op B took an eternity since it first waited many seconds >>> until the slow op A you yourself launched in the same session finished; >>> after that, A took about 100 ms of its own time. But this kind of >>> explanation would not do with plain users at all :( >>> >>> Could anybody see any practical solution? >>> >>> Note please that making _all_ R/R lightning fast is practically impossible >>> (we would have to refactor too heavily, not an option in a near future). >>> Besides I am afraid even if we somehow succeeded to make all R/R reliably >>> belong a second or so, they would still launch ten second-long operations >>> in ten windows plus one 100 ms in another, and then complain that the last >>> one took seconds too :( >>> >>> At this moment about the only solution very ugly work-around I can think of >>> would be to choose a couple of the trivial operations whose speed the users >>> consider most important, and re-write them without session (they would >>> still need to work with the session ID, but important things like the >>> current user etc. would have to be cached in the application in some kind >>> of static map without using the Session instance at all). Sigh. Darn >>> complex, but still worlds easier than attempting to make _all_ R/Rs >>> 100ms-or-less... >>> >>> Any better idea? >>> >>> Thanks and all the best, >>> OC >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >>> <mailto:Webobjects-dev@lists.apple.com>) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com >>> >>> <https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com> >>> >>> This email sent to aa...@chatnbike.com >> >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
