I'm writing a PHP script. I've got a form uses post method and action to another page. If an error occurs, I show a message on that target page, and let the user go back via a link that triggers history.back(); javascript function.
So user clicks that link and turns back to the page includes form and values entered by user should remain in inputs.
They stay on Chrome, but lost in Firefox. Is there a way to keep DOM information on all major browsers using history, or is the only way to do that is to use a cache like session, cookies, etc. ?
You could, and I know it's annoying, capture your POST data and turn it into SESSION variables, then repopulate input fields on browser back.
Alternatively, You can submit the form to an iframe and process, or use ajax to process and depending on the result, trigger a new page load or not.
Related
Did puting autocomplete off on input text say to the browser to not remember the text or only not using it?
I have textbox with personal things and I want to be sure it cannot be retrieve on a public computer.
According to the MDN Page regarding HTML autocompletion, browsers will not save data if autocomplete is turned off for that form or field:
Setting autocomplete="off" here has two effects:
it stops the browser saving field data for later autocompletion on similar forms though heuristics that vary by browser.
it stops the browser caching form data in session history. When form data is cached in session history, the information the user has filled
in will be visible after the user has submitted the form and clicked
on the Back button to go back to the original form page.
Yes, I would have all frames under the same URL.
It seems to save a decent amount of typing if I just submit a form to an iframe, get the contents of the frame document, and do whatever I need with them on the parent page. (Display errors with the form after submission, for example)
So why not just submit to a frame instead of AJAX?
EDIT:
https://stackoverflow.com/a/362743/870729
While iframes are meant for content embedding, one must remember that they are used quite often for other reasons. One example would be a dynamic upload form, that displays the upload progress with jQuery or something.
In my case specifically, when a user submits a form, I want to return ONE number.
For example, if the user submits the signin form, and the result is 0, the username they entered does not exist. 1 would be an incorrect password, etc.
I would do something like this in JS then:
if(response==2){ //let's just say that '2' is "no errors"
displayMessage("You have signed in successfully!");
}
EDIT:
Thank you everybody for your answers. I will just use AJAX in this case. Special thanks to #cale_b.
That would work, but it may be difficult to get the information from your iframe to your parent page. What event would you use, frames[0].onload = function(){}?
As with this answer to Are iframes considered 'bad practice'?, iframes will cause the browser to look like it's loading, and will make the browser's back button navigate the iframe back to the previous state. This might be what you want, and it might not be.
I am sure everybody knows that behaviour. You fill in a form on the web, and you submit it. After the submission you recognize that you filled in some wrong data. So, you click on the browsers back button. Then, sometimes the form still have the data you entered (what you are hoping in this situation) and sometimes not.
I couldn't find any connection when it is cleared and when not.
Some answers i found on the internet / stackoverflow:
on https connections, forms are always cleared
when using dynamic websites with sessions, forms are always cleared
But both of them are definatly wrong. I have seen sites (like one of my own) that does keep the form-data after the browser back and are using https and are using sessions.
So please: can anybody explain me how browsers are handling this stuff?
By the way: my task is it to make sure that the form data is not cleared.
I can't provide the definitive answer for all scenarios.
As a web developer, here's the rule I generally follow for sites I develop, to accomplish the goal of not letting the user lose data:
Disable all caching (via HTTP headers) on the page you want retained.
Capture all data into session (or some other temporary storage) when the form is submitted.
If the user navigates backwards, the browser requests a new version of the page (because you set it to never cache).
The page has logic to look to the session/database/wherever and repopulates all the fields based on the last input state. If there were dynamic inputs on the page, you should have enough data to recreate them.
Once the process is finished, use a POST/Redirect/GET pattern to clear the session data and make it difficult for the user to go back to the original page.
Some answers i found on the internet / stackoverflow:
1. on https connections, forms are always cleared
2. when using dynamic websites with sessions, forms are always cleared
I believe #1 varies by browser/security settings/scenario.
Assumption #2 is certainly not true in all cases (the pattern I just described leverages session and dynamic forms).
Its a browser issue. Browsers behave differently when the back button is clicked.
This question was asked before here Losing form data when clicking the back button on browser
I was wondering about the best way to implement a "Confirm Page" upon form submission. I know that it's best for the script that a form POSTs to be implemented by handling the POST data and then redirecting to another page, so the user isn't directly viewing the page that was POSTed to.
My question is about the best way to implement a "Confirm before data save" page. Do I
Have my form POST to a script, which marshals the data, puts in a GET, and redirects to the confirm page, which unmarshals and displays the data in another form, where the user can then either confirm (which causes another POST to a script that actually saves the data) or deny (which causes the user to be redirected back to the original form, with their input added)?
Have my form POST directly to the confirm page, which is displayed to the user and then, like #1, gives the user the option to confirm or deny?
Have my form GET the confirm page, which then does the expected behavior?
I feel like there is a common-sense answer to this question that I am just not getting.
If you must do this (I'd only do it for stuff involving monetary transactions or the like, personally), I'd recommend 2 resources/URIs, both of which follow the Post-Redirect-Get pattern: POST the initial cart checkout, create a "pending order" state (or similar), redirect to the page for that state. The user can then POST from that page to the next URI to create a "confirmed order" (or similar), which redirects to a receipt page or whatever.
What I've done in the past is have one page that has a 'View' area with labels and then a 'Edit' area with textboxes/dropdowns/etc. You can make them DIVs or TABLES depending on your preference.
User comes to page and gets the edit view so they can use the textboxes. Save/Submit button at the bottom.
Clicking on Save/Submit does a postback, populates the labels with the data they entered, and allows them to view/verify what they entered. Continue and Edit buttons at the bottom.
Edit is a postback and goes back to the edit view.
Continue does the actual save and redirection to a new page that displays the confirmation.
Optionally you could save the data on the confirmation page instead of the first page depending on your preference again.
Actually, you could do this ahead of the submit. In the form submit (wherever that is) add an onlick that fires a modal window with a confirmation button. My personal favorite in this situation is to use a Jquery UI Modal Confirmation dialog.
I personally fire this via means of a Jquery .click statement in the page.
So, the document won't submit until the onclick dependency has been completed and changed to "true" which the example does automatically with the included "ok" button.
I believe that this will gracefully fallback to just not require the confirmation if Javascript is turned off, which itself is becoming more and more of an "edge" case. In fact, some of my most staunch corporate clients are starting to accept limitations such as this case when Javascript is turned off....and they're way more picky that most any of us ever will be.
Then, you're free to submit to any page you'd like. Personally, I've switched all of my forms over to a Jquery .ajax submit, but that's just me. You can do it however you like.
I have a form with multiple submit buttons, each of which is relevant to how the user wants the data saved and/or loaded.
The problem is (or was) that if a user pressed enter on the last (or any other) input within the form, the submit button that seemed to be called was the "load saved formed" which is at the top of the form. All attempts to user javascript to have the return button default to the "save form" seemed useless, almost as if the browser was too busy already submitting the form to have any js interfere.
Finally, in FireFox 3.5, I actually had the server-side script echo out what it received for the post variable and discovered that none of the submit button values were being passed back to the server. As it turns out, I have hooks in the script for when the user hits "Save" or "Save and Print", etc, but if the user uses the "load page" it simply updates a variable and continues loading the page normally with that variable in context.
So with no submit button value at all, it did the same thing, it simply loaded the page.
So, on to the big question:
Is this typical browser behavior? Maybe even reliable browser behavior? Will hitting enter always submit the form as though no submit button was pressed at all, or do some browsers like to pick a button to use as the default when the user presses enter?
If it is typical behavior, what is the suggested course of action? I was going to have the script save anything no matter what, so long as there was data in the form, but then I realized that this was even more dangerous, because if the user loads one saved form, changes there mind, and changes the form dates and hits "Load Form", then it will save the form data from the pervious form for the new dates they have requested.
I considered setting it up so that changing the load form inputs (selects with dates and other particulars) would clear the form so that the server still recieved an empty form and thus would not overwrite any previous data, but this is risky as well, as many users will certainly notice and think that their data has been lost, etc, and there is always the slight chance that the user will be almost done with the form, go up to the top and fiddle with the form-load selects just to confirm they chose the right what nots and then be forced to start from scratch.
I should just have two forms, one for loading, one for the data, but the problem with that is that all of the data in the load part of the form does get used by the main form. I could write more js to combine the two on submit, or hide the data in the second form, but all of that seems clunky.
Essentially, I need a setup such that the top part of the form is independent of the main form, but not vice versa. Submitting the upper form does not submit the lower, but submitting the lower does submit the higher.
Okay,I've gone on long enough. Basically I'm wondering if a solution already exists or if anyone else has run into this and found a clever fix. I thought simply having the form save whenever the form wasn't empty was pretty clever, until it occurred to me that when the user goes to the page, it auto-loads the most applicable form given the date, and thus changing the load variables will almost always caused trouble.
Having read the possible duplicate that Artelius was good enough to draw my attention to, I'm still unclear on the consistency across browsers regarding the Enter button as submit.
It seems that almost everyone in that question assumed that hitting enter presses the first available submit, which was also my assumption until a friend suggested I hide (via CSS) another submit button at the top of the form with whatever I wanted enter to achieve. It was when this got me the same results that I finally viewed what was being passed to the server (ie nothing in terms of a submit value). So that means either
a) the "enter as no submit button just submit" is new behavior for some or all browsers,
b) the "enter as just submit" vs "enter as first submit button" is just browser choice, no trends, just typical cross-browser unreliability, or
c) Everyone just keeps assuming that the "enter as first submit button" is the case because most of us only code if (situation1) else (assume not situation1) and none of us are really sure what the browser is doing.
I highly doubt it's that last one, but then again, I also highly doubt most of us know which browsers do which. I'd sure like it if there was a straight answer I could pass along.
Oh, and finally: While I know it would be far simpler to use buttons, and I am taking that under serious consideration, I would also like to consider other options, since really the only need for less submit buttons I have is for when users hit enter instead of one of the buttons.
Actually, let me get carried away one more second:
The only thing I really need to know is whether or not they hit enter FROM one of the text inputs. If I could pass that along to the server, I'd know if I should save or reload the form. But the problem is (or at least what I've had troubles with) is that when the user hits enter in an input, it seems like there isn't any more playtime with js to capture anything, and in some cases, it seems like the browser is triggering the onclick for whichever submit button and thus not really allowing me to know the real event that triggered that. I'll play around more with jquery, but has this behavior been observeed by anyone else?
My best advise would be to only have on submit button, and let that submit what ever is the most common usage of the form. Let the rest of the buttons just be normal buttons, which you can hook click events onto.
Just make sure you make it very clear which button will be "pressed" when the user hits enter. Let the submit button be the biggest one. If you have 3 buttons that are used equally as much, I would just drop having a submit button at all...
edit: I'm pretty sure most browsers will post all the data inside a form. If you want to do some checking on the data before posting you could add a listener for onsubmit
<form onsubmit="checkData(this);" ... >
Passing in this will let you check which form is actually being submitted:
function checkData(form) {
var formName = form.id;
//check all the data based on which form is being submitted
}
The HTML5 spec specifies synthetic click activation steps for implicit form submission:
A form element’s default button is the first Submit Button in tree order whose form owner is that form element.
If the user agent supports letting the user submit a form implicitly (for example, on some platforms hitting the "enter" key while a text field is focused implicitly submits the form), then doing so for a form whose default button has a defined activation behavior must cause the user agent to run synthetic click activation steps on that default button.