💾 Archived View for bbs.geminispace.org › s › Lagrange-Issues › 81 captured on 2024-08-18 at 19:19:02. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-07-09)
-=-=-=-=-=-=-
Android 1.17 B27 2024-04-20
I've seen it before but was unable to get a consistent demo until now.
The problem occurs when a dynamically-generated page based on user input loads and contains a link requesting more input, with the same URL. Canceling input should redraw the page as it was shown, but instead, backs up in history to show the previous page!
gemini://tilde.cafe/~stack/DicePoker/live/poker
Play a couple of hands normally;
Note the dice rolled during a new round, and click on the link to open the selection input box;
Now, hit CANCEL;
Observe that Lagrange redraws the previously selected dice, the end of the last move!
Now Lagrange is showing the wrong screen, and hitting the NEXT link brings up a selection box for the current dice, which are no longer displayed! Confusion ensues.
Upon cancelation of input, Lagrange should render the exact page that invoked the input field.
Lagrange seems to pull up the previous page from history, as if hitting cancel also does an implied BACK operation.
Once redrawn, the URL likewise shows the ?... input data matching the incorrect screen being displayed, and not the URL of the correct screen that caused the input field.
🐞 Issue #81 in s/Lagrange-Issues
May 24 · 3 months ago
🚀 stack [OP] · May 24 at 15:19:
Linux Version 1.17.6 is behaving identically!
🕹️ skyjake [mod...] · May 24 at 15:36:
The back navigation when cancelling an input prompt is not a bug. However, in this case the problem is that the URL that requested user input is the same as the one where the URL was opened from. In a typical case these would be different, so you'd want to get back to the page where the opened URL was found.
I'll have to think this through a bit, but it's probably OK to not do the back navigation when the previous URL is the same as the query URL.
🚀 stack [OP] · May 24 at 17:32:
You render a page with an input link. Clicking on such a link does not change what is displayed, and brings up an input dialog in the foreground. Canceling it should absolutely keep what's on the screen and not back up! Anything else is clearly incorrect behavior.
In a more 'usual' case the input link points at a different URL which does not render. If your code counts it as 'new page' in the history -- even though the previous page is still displayed -- you can express the act of redrawing the invoking page as 'backing up', although it is a wrong way to think of it.
The act of redrawing the invoking page is _implemented_ in your system in terms of backing up, but it semantically is not!
This is a semantic issue with the spec... What is a page unit, in terms of caching? Clearly, an input URL is not a first class page, since it does not render, the invoking page is still displayed, and in case of cancelation, you don't want to reload the input URL and be stuck.
So in terms of caching and back/forward navigation, the page with the input link being displayed is a first class unit, the one to return to upon canceled input. The link URL is not a first class unit, and should not be a part of the navigation path, as it usually relies on the previous URL being rendered below. And it's just confusing, and I would argue, never what the user wants.
There is a strong case for handling this correctly. A CGI script can and should be able to sit at the same URL and take different input. It has no way of knowing that the browser had failed to render the correct page! Or what it's displaying. Or that input was canceled.
From the app, we have to assume that when a particular input is requested, the browser is displaying the very page that contained the link that activated such input. There is no synchronization mechanism to verify it and we have to rely on the correctness of implementation!
Even as is, the backing up is not correct -- just because the input URL is at the same address as the invoking URL, backing up should not skip it to render the previous page, also at the same address.
A. ...?66. 20. Render part 2 of round 4
User clicks next
B. ...? 20. Render part 1 of round 5
User clicks to hold
C. ..? Xx Input (Can't remember the code)
User cancels.
How can anything but B be backed up to?
I obviously have no idea about how you cache pages, but it seems that even if backing up, something is broken in the logic. Just because the URL address is identical, an extra backup step should not be taken!
🕹️ skyjake [mod...] · May 25 at 04:59:
Thanks for the detailed feedback. I will look this over carefully.
The back navigation when cancelling an input prompt is not a bug.
By "not a bug" I mean the back-on-cancel is intentional. But as you point out, there are some subtleties involved when it comes to input queries: are they actually pages where the user navigated to or not, and how do they interact with the history. I've spent a fair amount of time on this in the past.
I do have a concern about your Dice Poker implementation, though. Is there no URL where you can just see the game state as is, without taking an action?
I've tagged this as #bug because I think there may be unintentional behavior in the management of the search history when opening a link that points to the same page where the link was opened from. It may be considered effectively a simple reload of the page.
🚀 stack [OP] · May 25 at 19:13:
DicePoker has serious problems, and I refer to it only as a toy to demonstrate the Lagrange issue.
I appreciate you taking this seriously.
🚀 stack [OP] · May 26 at 02:43:
What I am trying to figure out now, is why this does not happen in Farkle? Hitting 'cancel' just leaves the page it came from intact, and that is also on the same URL...