Closed
Bug 119324
Opened 23 years ago
Closed 22 years ago
Going back to a page loses text/value attributes of list box items (select / option)
Categories
(Toolkit :: Form Manager, defect)
Toolkit
Form Manager
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: tatu.saloranta, Assigned: john)
Details
Attachments
(1 file)
|
(deleted),
text/html
|
Details |
When navigating from a web page that has form with select (list box)
form control to another web page and then back, 'text' and 'value'
attributes are lost (at least when values were changed from
javascript). This is different from behaviour of NS4.7x, and a
problem when developing a web app. In my case I'm storing internal
app data in list box (in a zero-sized frame) for easy accessibility
(easier to index). Text fields seem to keep the value changes
correctly. For the web app I'm developing this is a nasty problem.
I can provide an example page, but it should be fairly easy to
reproduce this.
|
Reporter | |
Comment 1•23 years ago
|
||
Forgot to mention that bug #41555 seemed to be similar to this one, but
not a duplicate (since text fields/areas do work ok now AFAIK).
Additionally, I have tested the problem on latest milestone (0.9.8)
on Linux, and on an older version (0.9.6+) on Solaris 8.
WFM, build 2002050608 win98; however, if you go over to the bugzilla query
page(http://bugzilla.mozilla.org/query.cgi), you can observe the effect you
describe in this bug for list boxes that are populated _dynamically_ (using
JavaScript, for example). _That_ effect/bug is visible on the bugzilla query
page because the list of values for "Version", "Component" and "Target
Milestone" change depending on what value the user selects for the "Program"
list box. So when you submit your query, and hit back (also happens with
refresh and forward), those values will not be remembered.
Are you using JavaScript to change the actual list of values in your list box?
Because if you are, then you are probably experiencing what I am describing, and
the summary should be changed (especially because I have just observed that, as
far as your original report goes, wfm). I am very curious to know whether
you're still having the problem and whether it is what I am describing.
Tatu, the situation I described here observable on Bugzilla's query page is
identical in IE6 and NS4.7. So it may never get fixed. This will probably end
up getting marked resolved wontfix even after you update the summary, unless you
can show that this bug is not seen in NS4.x or IE or some other browser; you
said it worked in NS4.x, but I am not sure how to show that myself. Could you
try doing that?
|
|
Reporter | |
Comment 4•23 years ago
|
||
Actually I re-verified the problem on RC2; it still exists. However, Netscape
4.78 on Linux is fine as well as Netscape 4.79 on Solaris. Unfortunately I can't
test it right now on IE, but I did test it before first report so I belive IE5
on Windows works as well. And like David guessed, the problem
is related to javascript initiated attribute changes (which is about
the only way to change them dynamically).
The problem occurs when updating select form control's options' text/value
attributes via JavaScript. I have attached a simple test page that can be used
to test functionality. (a sidenote: make sure you have some disk cache allocated
on Netscape 4; otherwise it may not restore form controls' values properly...
probably not the case with Mozilla any more).
Also... this test displays another bug (didn't verify if its reported or not);
combobox title (on Linux) does NOT get properly updated based on change
of text attribute either; works on NS4.7x.
A simple test:
(1) Open the page
(2) Press 'get' button; text field should now display 'default'
(3) Modify 'default' to something else, like 'custom'
(4) Press 'set' button; observe changes in select controls (and also see
the related bug with combobox title)
(5) Clear text field, press 'get', text field should get the new value
you entered in 3rd step ('custom')
(6) Go to another web page (I typed URL in address bar)
(7) Go back
(8) Notice that list entries have reverted to their old descs (text attribute
not restored).
(9) Press 'get'; indicates that 'value' was not restored correctly either.
And here's a simple test page:
---
<html><head>
<script language="javascript">
function doGet(form) {
form.textCtrl.value = form.listCtrl.options[0].value;
}
function doSet(form) {
form.listCtrl.options[0].value = form.textCtrl.value;
form.listCtrl.options[0].text = "Entry: "+form.textCtrl.value;
form.listCtrl2.options[0].value = form.textCtrl.value;
form.listCtrl2.options[0].text = "Entry: "+form.textCtrl.value;
}
</script>
</head>
<body><form>
<select name="listCtrl" size="4">
<option value="default">Entry: default</option>
</select><br />
<select name="listCtrl2" size="1">
<option value="default">Entry: default</option>
</select><br />
Option value:<input name="textCtrl" type="text" value="" /><br />
<input type="button" onClick="doSet(form)" value="Text to option (set)" />
<input type="button" onClick="doGet(form)" value="Option to text (get)" />
</form></body></html>
|
|
Reporter | |
Comment 5•23 years ago
|
||
Small addition; Opera 6.0 on Linux works correctly as well as Netscape 4.7x.
I see that you are right that your example works in Netscape 4.79 (that is, form
values are remembered) and not in Mozilla. But I completely misunderstood what
you were referring to (completely my fault). My example (about Bugzilla's query
page) was not about whether a browser remembers a dynamically populated list of
possible option values; it was about whether Mozilla would remember which
elements from such a list were selected. It is interesting to note, however,
that Netscape 4.79 does both things correctly also. I wonder if the problems
are related; they could be if the issue is script handling of form data and
elements (the entire state of the form should be saved, not just the
user-selected values for static elements).
|
|
Reporter | |
Comment 7•23 years ago
|
||
Yes my mistake too; I didn't thoroughly check the problem you described.
Seems likely that all 3 problems are related however, and hopefully can
be fixed at same time as well. It certainly seems that it's just a question
of not saving element values beyond selection status.
One thing I was wondering was could you quickly check if IE works like
NS4 (it seems latest Opera does at least), since I don't have a working
Windows installation on my machine right now?
IE6 for Win 98 does not work like NS4, it acts like Mozilla (values are not saved).
|
||
Comment 9•23 years ago
|
||
Form value restoration issue. Over to jkeiser.
Assignee: radha → jkeiser
Component: History: Session → Form Manager
|
||
Comment 10•22 years ago
|
||
Select box values are populated dynamically by JavaScript. Mozilla does not
remember them on forward/back/refresh. (IE 6 does not either, but NS 4.79 and
Opera 6 do).
|
Assignee | |
Comment 11•22 years ago
|
||
save / restore currently only saves information that the user can directly
change, and that's not going to change. We don't save the DOM, we just save
user-changed form elements.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
|
|
Reporter | |
Comment 12•22 years ago
|
||
Well, that really truly sucks from web app writer perspective. :-/
Of course had I done what most of the herd does (written my code on
IE to begin with), I wouldn't even have noticed this works on
some platforms...
List boxes seemed like the most effective (somewhat) persistent
storage mechanism HTML/DOM had on browsers, allowing easy indexing.
Does this also mean that no non-interactive changes to text fields and
text areas are saved either? Or is the decision made on case-by-case basis?
(text input controls, yes, lists, hidden fields on?)
|
|
Assignee | |
Comment 13•22 years ago
|
||
If you're writing to standards, you really shouldn't expect any saving and
restoring at all. In fact, if we were standards-compliant and cared more about
the webpage writer than the user, we wouldn't save and restore at all. It's bad
for data integrity.
Values set by JS will be saved as well--it is any value that *can* be changed by
the user that are saved and restored.
|
|
Reporter | |
Comment 14•22 years ago
|
||
> If you're writing to standards, you really shouldn't expect any saving
> and restoring at all.
>...we wouldn't save and restore at all. It's bad for data integrity.
That is assuming you consider going back and forth between pages to
be loading/unloading and requiring restoring. If your point of view
was just that page is alive it should NOT revert any values whatsover
up to and including form control values (no need to do unload/load).
I'd say restoring values may be considered to be bad for data integrity
but mostly because some values are stored/restored, some not, instead
of just leaving all values as is for duration of page's life span.
(in fact like you said it'd be best to not even restore form values...
but apparently back then users were complaining too loudly about that
esp. as earlier netscape versions reloaded on page resize)
But enough about the subject -- considering existing implementations
what you are saying makes it a reasonable approach.
Thanks also for the comments, it's good to know the reasons behind
deciding not to change the behaviour.
> Values set by JS will be saved as well--it is any value that *can* be
> changed by the user that are saved and restored.
Ok. Fair enough. Perhaps I'll just create a matrix of text fields for
my needs. :-)
You need to log in
before you can comment on or make changes to this bug.
Description
•