Going back to a page containing form data
Timothy Daniels
Safari in re-loading an HTML page with a form in it. The form
has a textbox and a textarea with prompts in them which get
cleared out when they first get focus (i.e. when the user clicks
with the cursor inside the fields). This clearing of the text
input areas should only occur the first time the user fills in the
form. If he should return to the page by using the Back button
on the browser (or on his mouse), the content which the user
filled in should still be there, and getting focus should not clear
the text from those areas.
The server gets back the contents of the form's fields in a
$_POST array from the browser. Various fields of that array
are copied to a SESSION array, and the elements of that array
are tested at the server now and then with the isset() function to
see if the user had input any data to the corresponding form field.
If he had, the corresponding field in the re-generated HTML form
will not contain prompts and no onfocus event handler will be
supplied to clear the fields.
This scheme works for the other 3 browsers, but not Opera.
Opera acts AS IF it didn't fill in the $_POST array because the
isset() on the SESSION copy of that array keeps indicating that
the array elements were not set (i.e. no data was entered into their
corresponding fields in the form). The result is that even after
inputting data to a field in the form, the field is cleared when the
user returns to the page by using the Back button and then puts
his cursor into the field. Does Opera fill in the $_POST array in
a way that is different from the other browsers? If so, how are
the data from the form fields arranged?
*TimDaniels*
Remco Lanting
http://www.opera.com/support/kb/view/827/
In other words, it's a feature. The DOM is kept, but not javascript vars
afaik.
--
Remco Lanting
[Unofficial Opera bug tracker links]
http://opera.remcol.ath.cx/bugs |
http://my.opera.com/community/forums/topic.dml?id=217364 |
remco.lanting...@gmail.com
Timothy Daniels
"Remco Lanting" replied:
Thanks, Remco. I have a little clearer picture of what's
going on, now, but not a total picture. I thought that I could
use a hidden field as a variable that would persist through
a refresh, but Opera (in its default setting) ignores it and so
doesn't save and restore it's value. Is there some way to do
the equivalent or to force Opera to save the value of a
hidden field?
BTW, how does one cause changes to opera:config
to be saved?
*TimDaniels*
Remco Lanting
Since Opera keeps the DOM, you could run javascript on page load to check
for it and act accordingly. Not sure if it the javascript will actually
run 'onload' again though :P
As for opera:config, you just hit the save button under the section you
changed something in.
Timothy Daniels
Thanks, again, Remco. I was able to work out the problem by
using homebrew "invisible" data fields on the page. Since Opera
seemed to be requesting a new copy of the form, but stuffing it
with data saved from the user's previous use of the form, I figured
that I could use that data taken and kept by Opera as session variables.
I tried using "hidden" fields (i.e. <input> tags with "type='hidden'"),
but it turned out that Opera doesn't save the values from hidden fields,
only the fields of type='text'. So I used type='text' fields that were
made invisible and bulkless by styling - visibility: hidden; padding: 0px;
border: 0px; margin: 0px; font-size: 0px; line-height: 0px; The
<input> tag had the class='invisible' attribute, where "invisible" was
a subclass of the "input" styling selector, so the tag looked like this:
<input class="invisible" type="text" id="......" name="......" value="",
and the value was accessed by:
document.getElementById('fieldId').value
The 2 possible values of the "value" attribute were the strings "true"
and "false", and they were tested in "if" statements as being =="true"
or not. With this "invisible" field, I could do without the SESSION
array back at the server to tell me whether this was the first time
the user had seen the form in that session using Opera. The same
logic also accomodated IE, Firefox, and Safari, so I didn't need any
server-side tests for the type of browser - the server-side code feeds
the same HTML and Javascript to all of them. Why Opera doesn't
save the values from "hidden" fields is a puzzle, but this is a way to
work around that.
*TimDaniels*
Ric
You're relying too much on JavaScript, when you already have a server-side
solution in place.
You could use JavaScript for disabling the form button once submitted, but
otherwise, just forget the JavaScript.
--
Ric
Timothy Daniels
> You're relying too much on JavaScript, when you already have a
> server-side solution in place.
> You could use JavaScript for disabling the form button once
> submitted, but otherwise, just forget the JavaScript.
>
> Ric
Care to explain what you mean and how to do it rather than
just to say "you're doing it wrong"? If you have a better understanding
of how Opera works, as opposed to other browsers, how about
explaining how it works differently and what to do about it? As a
basis of comparison, my way of using an "invisible" field to trick
Opera into returning an otherwise "hidden" field to the server works
in IE7/8, Firefox, Opera, and Safari. Now, how would *you* go
about solving the session variable problem?
And, BTW, the problem is *not* about preventing the user from
clicking the Submit button twice.
*TimDaniels*
Ric
<NoS...@spammeknot.biz> wrote:
>
> Care to explain what you mean and how to do it rather than
> just to say "you're doing it wrong"?
No, you are doing it wrong, learn to do it right. It's not my job to teach
you how to manage a website.
> If you have a better understanding
> of how Opera works, as opposed to other browsers, how about
> explaining how it works differently and what to do about it? As a
> basis of comparison, my way of using an "invisible" field to trick
> Opera into returning an otherwise "hidden" field to the server works
> in IE7/8, Firefox, Opera, and Safari. Now, how would *you* go
> about solving the session variable problem?
>
It has nothing to do with browsers, I was giving you a hint that you are
going about it the wrong way,
Now if there's a bug in Opera, which I'm beginning to see there may be
(but not necessarily related to your problem), that is an issue. But from
your post you seem to want to control the user's side of the browser, and
that just isn't an option you have.
--
Ric
Ric
> Now if there's a bug in Opera, which I'm beginning to see there may be
> (but not necessarily related to your problem), that is an issue. But
> from your post you seem to want to control the user's side of the
> browser, and that just isn't an option you have.
>
The bug in my code, I discovered is in this line
onclick="this.value='Sending';this.disabled=true;return true;"
And the solution is to change it to this
onclick="this.value='Sending';return true;this.disabled=true;"
Which really isn't the proper fix, as I look at the code, I realize I
probably need to use javascript to submit the form as well, rather than
trying to do that with the return.
onclick="this.value='Sending';this.form.submit();this.disabled=true;return
false;"
So in other words I was doing it wrong, there is no browser bug.
And this may or may not disable the submit button when someone clicks the
back button, but the client side is not something I can control.
Get it?
--
Ric