[1.4.0.?] Inconsistent Form Handling

Confirmed bugs should get a single post here. Check the READ ME FIRST sticky thread for the format.

Moderators: dorpond, trevor, Azhrei, giliath, jay, Mr.Ice, MapTool BugReport Manager

Forum rules
Posts that do not conform to the READ ME FIRST sticky thread are subject to deletion.
Post Reply
User avatar
SeulDragon
Kobold
Posts: 3
Joined: Sat May 28, 2016 1:35 pm
Location: New Mexico

[1.4.0.?] Inconsistent Form Handling

Post by SeulDragon »

Overview: When a form is submitted from a dialog or frame roll option and the form has a combo box, the data passed from the combo box is differently formatted when using a submit input type then when using an image input type.

Versions: 1.3.89, 1.3.91, 1.4.0.1, 1.4.0.2, 1.4.0.3, 1.4.0.4, 1.4.0.5

Expected behavior: Regardless of the method used to submit the form, the data passed to the responding macro should be formatted the same, as determined by the action method value.

Observed behavior: When using a submit input type, the data for combo boxes is passed as expected. However, when using an image input type, the data for combo boxes passes the text of the option, rather than the value of the option.

Example:

Code: Select all

<select name="selectedItem">
  <option value="none">The option is none.</option>
  <option value="one">The option is one.</option>
  <option value="many">The option is many.</option>
</select>
Data passed if input type is submit (Expected behavior):

Code: Select all

{"selectedItem":"none","button":"Check Output"}


Data passed if input type is image:

Code: Select all

{"selectedItem":"The option is none.","button.value":"Check Output","button.x":"84","button.y":"25"}


The value of selectedItem should both be formatted as the submit input type does.

Additional Information:
This behavior is the same for all versions of the 1.4.0 series of releases, as well as 1.3.89 and 1.3.91
The same behavior occurs with a dialog or a frame.
Having only one button on the dialog (of either type) does not change the behaviors observed for that button type.
The value of selectedItem is the only input that is returned differently depending on what type of submission method is used. The buttons also function as expected, even when the combo box information is different.
Changing the action method to string properties rather than JSON produces the same results.

I have attached a token with some test macros to show the different outputs, in both JSON and strProps. Both the image button and the submit button call the same responder, which simple outputs the information. I have stripped it to the one case that is different, but it can be used to test any type of input.

I ran across this when I switched a button type on a dialog panel to make it prettier, and suddenly the switch statement in the responder stopped working, as the value being passed was changed.

I could not find anything in the code that jumped out and suggested why these two input methods would cause the combo box to be handled differently depending on the submission type, but I am not very experienced with Java, and so could be missing something obvious. On the other hand, it could be a swing problem doing something unexpected behind the scenes or something much more subtle in code. Thus I pass it to more capable hands.
Attachments
LibTest.rptok
Token with macro example code showing the difference in the two form submission data results
(72.85 KiB) Downloaded 63 times
"The more complex the mind, the greater the need for the simplicity of play."
- Captain James T. Kirk (Shore Leave Stardate 3025)

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: [1.4.0.?] Inconsistent Form Handling

Post by aliasmask »

That does seem wonky. The "value" should be what is passed for the selectedItem rather than the option text. The naming convention changes too from button to button.value.

User avatar
SeulDragon
Kobold
Posts: 3
Joined: Sat May 28, 2016 1:35 pm
Location: New Mexico

Re: [1.4.0.?] Inconsistent Form Handling

Post by SeulDragon »

The naming convention changes too from button to button.value.
The change to the "button" name is due to the extra information passed from an image, which includes the x and y coordinates and the value of the input. This information matches what the W3C says an image input should pass, and looks like what I would expect to see from an internal structure object.property notation. The button name is only because I called the image input button, if I called it peanut, the output switches to this:

Code: Select all

{"selectedItem":"The option is none.","peanut.value":"Check Output","peanut.x":"94","peanut.y":"35"}
while the actual submit button remains the same.

What is baffling to me is that the image input is being passed properly, but it is causing something else to be passed incorrectly, which works otherwise. I can't find anything in the combo box code that should care, but I am also not sure I am finding all the combo box (or data parsing in general) code.
"The more complex the mind, the greater the need for the simplicity of play."
- Captain James T. Kirk (Shore Leave Stardate 3025)

Post Reply

Return to “Bug Reports”