| View previous topic :: View next topic |
| Author |
Message |
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3140
|
 Posted: Tue Jan 30, 2024 11:36 pm Post subject: HTML, IFRAME, form submission and autofocus |
 |
|
Yes, yes, I know, iframes are bad, do not use, yada yada...
Anyway, I have an iframe with a simple form, a text input and a submit button. Text input is flagged with autofocus attribute.
 What works:
I visit the page. My text input is active, waiting for me to start typing.
What doesn't work:
I hit [Enter]. The form posts the input and gets reset with http 303 (because apparently browsers don't understand http 205  ; 302 acts the same as 303 and is even less correct ), and suddenly the input is no longer active, since the iframe containing my form stole the focus.
What I want:
I want the form to post to the server, reset content, and activate the first input. Immediately, without client-side scripting (no js) or user nagging, and without reloading the whole page (because reasons).
What I tried (except for all the thing I threw at the wall that didn't stick at all):
Refresh with [F5] activates input again, but it also defeats the purpose of using iframes. And it is a key press.
I can activate the input by hitting tab. You could say one key is not a big deal, but it is annoying to me and will confuse unsuspecting individuals, which makes current behavior unacceptable.
Any ideas what I'm missing? How do I get a form I can easily fill a number of times?
_________________
Make Computing Fun Again |
|
| Back to top |
|
 |
Banana
Veteran
Joined: 21 May 2004
Posts: 1393
Location: Germany
|
| Posted: Wed Jan 31, 2024 3:22 pm Post subject: |
|
|
Do you have an example of the code?
The closest on information to 205 and your problem is this here: https://evertpot.com/http/205-reset-content
So, yes you can not use 205 in a plain html browser context without any danymic client JS.
| Quote: | | I want the form to post to the server, reset content, and activate the first input. Immediately, without client-side scripting (no js) or user nagging, and without reloading the whole page (because reasons). |
And whay in an iframe? Using Aform in a simple html page and doing just what you SAID, and send a header location with the same address instead as the response?
_________________
My personal space
My delta-labs.org snippets do expire
PFL - Portage file list - find which package a file or command belongs to. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3140
|
| Posted: Wed Jan 31, 2024 4:52 pm Post subject: |
|
|
Alright, so we have 2 distinct problems here:
1. 205 being not implemented properly in browsers. I don't think I can fix it, but there is a workaround.
2. The workaround does not retain focus. I hope this is the one we can actually solve, somehow.
AD1:
| rfc2731 wrote: | For example, a 204 status code is commonly used with document editing interfaces corresponding to a "save" action, such that the document being saved remains available to the user for editing.
[..]
The 205 (Reset Content) status code indicates that the server has fulfilled the request and desires that the user agent reset the "document view", which caused the request to be sent, to its original state as received from the origin server.
This response is intended to support a common data entry use case where the user receives content that supports data entry, enters or manipulates data in that space, causes the entered data to be submitted in a request, and then the data entry mechanism is reset for the next entry so that the user can easily initiate another input action.
|
Contrary to that blog | Quote: | | 205 Reset Content is somewhat similar to 204 No Content. |
and other secondary sources, those 2 are not supposed to be similar.
Unfortunately, during my quick tests browsers treated 205 the way they are supposed to treat 204: they post the inputs, and keep the changes as opposed to posting the inputs and dropping changes. The RFC doesn't leave any room for interpretation. Send and retain vs send and reset.
Anyway, I'm not fixing all browsers. This RFC has been around for 10 years, and the concept must be much older; _clearly_ the common data entry use case is not very common after all, so let's move on to the workaround below.
AD2:
It's just a proof of concept (for something else actually, but I encountered this bump on my way there), so there is barely any code at all, and I am still taking shortcuts, and also the code is a mess. Anyway, this is what the browser sees:
| Code: | <HTML>
<HEAD><TITLE>title</TITLE></HEAD>
<BODY>
<IFRAME src="/some_document" title="keep this part loaded"></IFRAME>
<IFRAME src="/input" title="the input form" > </IFRAME>
</BODY></HTML>
|
| Code: | <HTML><HEAD><TITLE>Input</TITLE></HEAD>
<BODY>
<FORM method="post" >
<input type="text" name="msg" value="" autofocus="true" />
<input type="submit" value="Bang!"/>
</FORM></BODY></HTML> |
Server responds to POST (submit button) with
| Code: | HTTP/1.1 303 xxx
Connection: close
Location: /input
Server: custom |
and drops connection.
Obviously, can't respond with 200 and a the new, empty form because it makes [F5] re-submit the form. After redirect the POST changes to GET and request body is dropped.
If I open the input form directly, it works properly. I navigate to the page, text input is active. I post it, page refreshes, the text input is active, rinse and repeat; it stays active. Good.
The same input form embedded in an iframe only works the first time I navigate to the page. After posting, the form refreshes but now it's the containing iframe that's active rather than text input, and i must at least hit [Tab] before typing. Bad.
_________________
Make Computing Fun Again |
|
| Back to top |
|
|
Banana
Veteran
Joined: 21 May 2004
Posts: 1393
Location: Germany
|
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3140
|
| Posted: Thu Feb 01, 2024 1:21 pm Post subject: |
|
|
Huh... Yes, this bug matches exactly. Thanks.
How did you find it actually? Bug reports tend not to just pop up in my generic internet search results.
| Quote: | | That is precisely correct, yes. Autofocus is not applied after the toplevel document is done loading right now, to avoid focus-stealing behaviors. |
I'd like to see the reasoning behind this decision. Oh, well...
| Quote: | | Personally I do not think you can do this without any JavaScript |
I guess you're not alone. I've seen a lot of similar things done in js or even java back in the days when applets were all the rage, but not a single one in pure html which _should_ have been much easier to do, and I wondered why, so that's a part of the challenge.
With bugs like that, maybe it wasn't just to look more cool  after all.
| Quote: | | It maybe could be done if you rethink the workflow or even application design. |
Maybe. Well, any ideas how else can I do a partial refresh?
I need a single view combining content user may or may not interact with (so we don't want to mess it up with a refresh), and a data entry form intended to be used multiple times in a row (so it must reset and refocus)
Splitting it into 2 windows is not good either, since it involves the user in organizing those windows, and that's work. Probably even more work than adding another [Tab] after every [Enter].
Well, if it ends up not working, it's just a challenge failed. Gotta take an L and move on.
_________________
Make Computing Fun Again |
|
| Back to top |
|
|
Banana
Veteran
Joined: 21 May 2004
Posts: 1393
Location: Germany
|
| Posted: Thu Feb 01, 2024 2:57 pm Post subject: |
|
|
| Quote: | | How did you find it actually? Bug reports tend not to just pop up in my generic internet search results. |
Dunno. Somtimes my google foo just works 
| Quote: | I need a single view combining content user may or may not interact with (so we don't want to mess it up with a refresh), and a data entry form intended to be used multiple times in a row (so it must reset and refocus)
Splitting it into 2 windows is not good either, since it involves the user in organizing those windows, and that's work. Probably even more work than adding another [Tab] after every [Enter]. |
I do not know your experience so please forgive me in advance and also it is simplified because I do not know everyhing.
HTTP is stateles: https://www.oreilly.com/library/view/hands-on-full-stack-web/9781788622882/46146c7a-c43c-4218-acf1-60a8b493f04e.xhtml
So the server does not know when the data is ready to be used. It only knows when everything is send. It does not know what the client is doing and when the client is ready. It only knows if the client makes a request, responds and then its done. Like a fire and forget missile (Again, simplified)
To know when and what will be focused can only be decided by the client based on the attributes the code has or by any client setting.
Each view in the client window (a client instance or a tab within the client) is one call and one result. So if you want to have two "windows" in the browser view, you will not be able to refresh them individually since it is always one request.
If you want two views/windows you need to "split" those views and make individual requests for each one. This is only possible by using client side code and tell the client to make another request and change the browser view part you want to change.
| Quote: | | I need a single view combining content user may or may not interact with (so we don't want to mess it up with a refresh), and a data entry form intended to be used multiple times in a row |
Why not use a single HTML document which displays the data and the input form. Send it and repond with the new data and a fresh input form? Keep the request data small, the user should be able to work quickly.
Again, this is simplified and there will be other solutions
_________________
My personal space
My delta-labs.org snippets do expire
PFL - Portage file list - find which package a file or command belongs to. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3140
|
| Posted: Thu Feb 01, 2024 4:31 pm Post subject: |
|
|
My experience is not that big, but http is simple enough I can implement it myself (at least the important parts); I mean, I am actually talking to the browser 
Yes, the current issues are on the client side, and it pretty much html rather than http now, so I'm focusing on that part even though there's more going on behind the scenes. However, if I can inject a server-side hack to influence client's behavior, I'm willing to do that for sake of keeping the client simple.
> Why not use a single HTML document which displays the data and the input form.
This is too tight integration. I want both things to be next to each other for easy interaction with the user, but I don't want them interfering with each other.
The other document might be another interactive form, or a potentially long text, which might be scrolled or highlighted or whatever user finds convenient. A full refresh will wipe local state, like content position relative to display, stepping on user's toes.
I know that pagination is a thing, but using too much pagination makes things difficult too. E.g. [Ctrl]+[F] becomes inefficient.
> Send it and repond with the new data and a fresh input form? Keep the request data small, the user should be able to work quickly.
This alone is ugly, but not too bad.
What if the response contains an embedded video though? Even if requests are small, the responses can get very big very quickly.
_________________
Make Computing Fun Again |
|
| Back to top |
|
|
Banana
Veteran
Joined: 21 May 2004
Posts: 1393
Location: Germany
|
| Posted: Fri Feb 02, 2024 8:58 am Post subject: |
|
|
| Quote: | This is too tight integration. I want both things to be next to each other for easy interaction with the user, but I don't want them interfering with each other.
The other document might be another interactive form, or a potentially long text, which might be scrolled or highlighted or whatever user finds convenient. A full refresh will wipe local state, like content position relative to display, stepping on user's toes.
I know that pagination is a thing, but using too much pagination makes things difficult too. E.g. [Ctrl]+[F] becomes inefficient. |
Another solution would be: The user should open two windows (or just drag a new tab out of the running browser) and place them side by side. One side the additional information and on the other side the input.
| Quote: | This alone is ugly, but not too bad.
What if the response contains an embedded video though? Even if requests are small, the responses can get very big very quickly. |
This depends how to implement the video. You could embed sources into the HTML response (https://www.iandevlin.com/blog/2012/09/html5/html5-media-and-data-uri/) but this is not the way to go. Usable if the data is small. The sane way to do is, use the correct html tag and provide the path to the source. This way the browser will load it as needed (and does some more magic) but would restart it.
As far I can understand your usecase, the thing you want to achieve is a usual one but complex one you can not build with only HTML. You need CSS for better layout control and JS to make it dynamic.
(Simplified. Not because it is too complicated but the reasons why something works that way are plenty and I do not now every one)
Like I said earlier, each browser window or tab within, is "one" request. The server responses with the code the client does understand. In this code (html and stuff) there will be more instructions what to do. Resulting in more requests, like loading images and more.
What you need is a side by side structure within the same window/tab. Can be done with a grid layout https://www.w3schools.com/css/css_grid.asp. Then you need XMLHttpRequest https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest_API (don't let the name fool you. You can send "any" data and not XML only), for processing your input form and refreshing only the part which needs to be refreshed without refreshing the whole window/tab.
There are complete frameworks which do everything for you and also in a nice way. I would suggest start simple but do not re-invet the wheel.
_________________
My personal space
My delta-labs.org snippets do expire
PFL - Portage file list - find which package a file or command belongs to. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3140
|
| Posted: Fri Feb 02, 2024 6:52 pm Post subject: |
|
|
Well, at this point I'm ready to just call the challenge failed. However, I got almost all I wanted from this proof of concept, so I don't agree it's to complex to be done without client-side scripting.
It fell just a step short of expectations due to an unimplemented feature I wanted to take advantage of, followed by a feature I did not expect to be there actively getting in my way. I'm actually considering reporting those 2 as bugs.
As the original idea revolved around an already long-solved problem, there is no point in me re-implementing it uglier and less convenient. Yes, there are js frameworks that can be used to patch things up, there are also other js apps doing the same thing. Making the exactly same thing again defeats the purpose of this exercise.
Thanks for help, it's time to move on to a different project; hopefully something actually useful this time 
_________________
Make Computing Fun Again |
|
| Back to top |
|
|
Banana
Veteran
Joined: 21 May 2004
Posts: 1393
Location: Germany
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
