Re: Going back to a page containing form data

[Timothy Daniels]

"Remco Lanting" replied:
> Timothy Daniels wrote:
>
>> I'm having trouble getting Opera to work like IE, Firefox, and
>> 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*
>>
>>
>
> 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

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.

--
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]

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]

The page isn't "reloaded" when someone goes back.
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]

> The page isn't "reloaded" when someone goes back.
> 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*