Opened 15 years ago

Closed 7 years ago

#5424 closed defect (fixed)

MappedTextBox: page refresh erases input values

Reported by: [email protected] 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 bill)

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: Gecko/20071127 Firefox/

HTML to reproduce issue:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
        <style type="text/css">
            @import "";
            @import "";
    <body class="tundra">
        <script type="text/javascript" src=""></script> 

        <script type="text/javascript">
                        djConfig = {
                parseOnLoad: true,
                isDebug: false,
                usePlainJson: true
        <input maxlength= "30" size= "30" id= "atextboxbefore">
		<select id="aselectbox" dojotype= "dijit.form.FilteringSelect" autocomplete= "true">
			<option value="a">a</option>
			<option value="b">b</option>
		<input maxlength= "30" size= "30" id="atextboxafter">

Attachments (1)

test.html (1.2 KB) - added by guest 15 years ago.

Download all attachments as: .zip

Change History (18)

Changed 15 years ago by guest

Attachment: test.html added

comment:1 Changed 15 years ago by bill

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?

comment:2 Changed 15 years ago by guest

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="">
		<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 class="dijitReset dijitRight dijitButtonNode dijitDownArrowButton" width="0%" dojoattachevent="onmousedown:_onArrowMouseDown,onmouseup:_onMouse,onmouseenter:					_onMouse,onmouseleave:_onMouse" dojoattachpoint="downArrowNode">

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 15 years ago by bill

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 15 years ago by Douglas Hays

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 14 years ago by bill

Milestone: 2.0
Summary: dijit.form.FilteringSelect overwriting html input refresh erases input values (dijit.form.FilteringSelect)

Marking for 2.0 for consideration.

comment:6 Changed 14 years ago by alex

Milestone: 2.01.3

Milestone 2.0 deleted

comment:7 Changed 14 years ago by bill

Milestone: 1.32.0

comment:8 Changed 14 years ago by bill

Description: modified (diff)

See also #6920.

comment:9 Changed 11 years ago by bill

Component: DijitDijit - Form
Owner: set to Douglas Hays

comment:10 Changed 10 years ago by bill

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:11 Changed 10 years ago by ben hockey

#6920 is a duplicate of this ticket.

comment:12 Changed 9 years ago by bill

#8201 is a duplicate of this ticket.

comment:13 Changed 9 years ago by bill

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 8 years ago by Douglas Hays

Owner: Douglas Hays deleted
Status: newassigned

comment:15 Changed 8 years ago by Douglas Hays

Status: assignedopen

comment:16 Changed 7 years ago by dylan

Bill, do you still want to keep this open, or have you addressed it with Delite/Deliteful??

comment:17 Changed 7 years ago by bill

Resolution: fixed
Status: openclosed

This is addressed by deliteful by requiring the app developer to put the <input> in their original markup, like:

Note: See TracTickets for help on using tickets.