Opened 12 years ago
Closed 4 years ago
#5424 closed defect (fixed)
MappedTextBox: page refresh erases input values
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | high | Milestone: | 2.0 |
| Component: | Dijit - Form | Version: | 1.0 |
| Keywords: | FilteringSelect overwriting input | Cc: | |
| Blocked By: | Blocking: |
Description (last modified by )
When adding a dijit.form.FilteringSelect? to a page if there is an HTML input after the Filtering select it will overwrite the value of the input if the page is refreshed. Any input above the control will be fine but the value of the input directly after the Filtering select will be overwritten. Further after some debugging I have found that if you give the FilteringSelect? control a name value e.g. name="fselect" it will stop overwriting the input's value with the selected value and just blank out the input's value. This only seems to be an issue in firefox. As well both FilteringSelect? and ComboBox? do not default back to the selected value after refresh in both IE 7 and firefox 2. To reporduce the issue, use the HTML below, populate the inputs with test, select an option in the FilteringSelect? and refresh the page with the browser refresh; you should see that the bottom input has the value of the selected item.
Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
HTML to reproduce issue:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<style type="text/css">
@import "http://o.aolcdn.com/dojo/1.0.2/dojo/resources/dojo.css";
@import "http://o.aolcdn.com/dojo/1.0.2/dijit/themes/tundra/tundra.css";
</style>
</head>
<body class="tundra">
<script type="text/javascript" src="http://o.aolcdn.com/dojo/1.0.2/dojo/dojo.xd.js.uncompressed.js"></script>
<script type="text/javascript">
djConfig = {
parseOnLoad: true,
isDebug: false,
usePlainJson: true
};
dojo.require("dijit.form.FilteringSelect");
dojo.require("dojo.parser");
</script>
<input maxlength= "30" size= "30" id= "atextboxbefore">
<br>
<select id="aselectbox" dojotype= "dijit.form.FilteringSelect" autocomplete= "true">
<option value="a">a</option>
<option value="b">b</option>
</select>
<br>
<input maxlength= "30" size= "30" id="atextboxafter">
</body>
</html>
Attachments (1)
Change History (18)
Changed 12 years ago by
comment:1 Changed 12 years ago by
comment:2 Changed 12 years ago by
I am not sure if there is an official spec but it is expected behavior in all of the browsers. If you remove the DojoType? attribute from the select element and refresh the page in either IE, Firefox, Safari or Opra it will retain the selected value upon refresh as well the inputs will retain their value. I will see if I can dig up whether or not it is an official spec.
Looking at the DOM tree I can see that the control is writing the following elements to the browser.
<table id="widget_aselectbox" class="dijit dijitReset dijitInlineTable dijitLeft dijitComboBox" cellspacing="0" cellpadding="0" wairole="presentation" dojoattachevent="onmouseenter:_onMouse,onmouseleave:_onMouse" name="aselectbox" role="wairole:presentation" widgetid="aselectbox" style=""> <tbody> <tr class="dijitReset"> <td class="dijitReset dijitStretch dijitInputField" width="100%"> <input id="aselectbox" class="" type="text" wairole="combobox" dojoattachpoint="textbox,focusNode" dojoattachevent="onkeypress, onkeyup, onfocus, compositionend" autocomplete="off" role="wairole:combobox" tabindex="0" value="" aaa:valuenow="a" aaa:invalid="false" aaa:disabled="false" style=""/> <!--Right here--><input type="text" value="" style="display: none;" name="aselectbox"/> </td> <td class="dijitReset dijitValidationIconField" width="0%"> </td> <td class="dijitReset dijitRight dijitButtonNode dijitDownArrowButton" width="0%" dojoattachevent="onmousedown:_onArrowMouseDown,onmouseup:_onMouse,onmouseenter: _onMouse,onmouseleave:_onMouse" dojoattachpoint="downArrowNode"> </td> </tr> </tbody> </table>
If you look where I put the comment “<!--Right here-->†you will notice that their is a input written by the widget that has no id associated with it. I am assuming that DOJO is using this input to preserve the last selected value since it has style="display: none;". I think that maybe because it does not have an id DOJO is getting confused as to which input it is looking for. This is only a hypothesis. If someone can point me in the right direction I would be more that happy to try to create a patch but I am not intricate familiar with how the ComboBox? / FilteringSelect? controls work on a display and post back level.
comment:3 Changed 12 years ago by
| Cc: | [email protected]… removed |
|---|---|
| Reporter: | changed from guest to [email protected]… |
We have two inputs because one shows the displayed value (ex: California) and one holds the actual value that gets submitted (ex: CA). We could probably add an id attribute to the hidden <input> without incident, and I guess that would solve the problem originally listed in this bug report, but I don't think it would make page reloading work as you described, because although the hidden input would be populated with the right value (same value as before the refresh), the widget wouldn't realize what had happened. The widget would think it's value was the one specified in the page markup.
Sounds like this would be solved by the "stabile" code from 0.4, which serialized and deserialized widget values when using the back/forward button.
Feel free to ping me on the #dojo IRC channel (I'm wildbill.)
comment:4 Changed 12 years ago by
Firefox will not fill in the last native input if you specify autoComplete="off" on it. I think firefox is just getting confused by the number of input's changing.
comment:5 Changed 12 years ago by
| Milestone: | → 2.0 |
|---|---|
| Summary: | dijit.form.FilteringSelect overwriting html input elements. → page refresh erases input values (dijit.form.FilteringSelect) |
Marking for 2.0 for consideration.
comment:7 Changed 12 years ago by
| Milestone: | 1.3 → 2.0 |
|---|
comment:9 Changed 9 years ago by
| Component: | Dijit → Dijit - Form |
|---|---|
| Owner: | set to Douglas Hays |
comment:10 Changed 8 years ago by
For 2.0 my thought was that we should get rid of all the hidden <input> fields (in other words, FilteringSelect would just have one <input> showing the "displayed value", not a hidden input containing the submit value).
Not sure if that's enough to solve this problem though; maybe just swap of the original markup for the template is enough to break things.
comment:13 Changed 7 years ago by
| Summary: | page refresh erases input values (dijit.form.FilteringSelect) → MappedTextBox: page refresh erases input values |
|---|
Marking as an issue for all MappedTextBox subclasses (including but not limited to FilteringSelect)
comment:14 Changed 6 years ago by
| Owner: | Douglas Hays deleted |
|---|---|
| Status: | new → assigned |
comment:15 Changed 6 years ago by
| Status: | assigned → open |
|---|
comment:16 Changed 4 years ago by
Bill, do you still want to keep this open, or have you addressed it with Delite/Deliteful??
comment:17 Changed 4 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | open → closed |
This is addressed by deliteful by requiring the app developer to put the <input> in their original markup, like:
<d-combobox> <input> </d-combobox>
Hi. Hmm, I'm not sure what the rules are for refreshing at all. It seems normal to me that when you refresh a page all the data you've entered will be erased, but maybe it's per browser? Is there an official spec on what's supposed to happen?