UI behavior

Question

Tmanchester 0 Newbie Poster

14 Years Ago

Howdy,

I am quite unskilled on UI but have been tasked with looking at behavioral problems on our site. It has been observed that the app acts differently when a user clicks on a submit button with a mouse versus tabbing to it and the pressing Enter on the keyboard. In particular, after a mouse click on the submit button on a specific page I see the data being updated correctly on the next page. In the tab-enter scenario, the data is not updated on the screen on the following page however, the db shows updated data and navigating to another page that shows data then has the correct data.

I have noted that our submit button is created through a custom tag (compounding my ignorance). Is this a commonly known bug/feature of HTML?

Regards,

Tim

jsp

3 Contributors
12 Replies
107 Views
1 Day Discussion Span
Latest Post 14 Years Ago Latest Post by Airshow

All 12 Replies

javaAddict 900 Nearly a Senior Poster

14 Years Ago

First of all what do you mean by custom tag?
Second, I believe that they should behave the same, whether it is clicked with a mouse or by pressing <Enter>. If I am wrong someone please correct me.
And third, is it possible to see some code?

Airshow 416 WiFi Lounge Lizard

14 Years Ago

Tman,

I suspect this is to do with some javascript handler, more particularly how it is attached to one of several possible "events".

Client side form-checking or pre-processing is typically invoked either when a submit button is clicked, or when the form is actually submitted. At first glance these may seem identical but are not.

Here is a demo:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title>Airshow :: Untitled</title>
<style type="text/css">
form { padding:20px; background-color:#e0f0f0; border:1px solid #669999; }
</style>

<script>
function formCheck(){
	alert('formCheck called');
	return false;
}
</script>
</head>

<body>

<form action="" method="" onsubmit="return formCheck()">
<input value="X">
<input type="submit" value="Go">
</form>

<form action="" method="">
<input value="X">
<input type="submit" value="Go" onclick="return formCheck()">
</form>

</body>
</html>

You will see that the two forms are slightly different. In the first, formCheck() is attached to the form's onsubmit event, whereas in the second it is attched to the Go button's onclick.

There are indeed behavioural differences, but unfortunately not quite as you have described.

In both forms, formCheck() is called whether we click "Go" or tab-enter, however there is a difference if we tab to the text field then enter - in the first form formCheck() is called, while in the second it is not.

This does at least demonstrate that there are differences in behaviour associated with the two versions. I tested in IE6 under Win 2000. It is not at all impossible that other browsers will behave differently.

Whereas I have failed to reproduce your symptoms exactly, I would suggest you start your investigation by looking for a javascript handler and see how it is attached to the form.

It is of slight concern that your submit button is created via a custom tag. This could be an issue. As javaAddict says, more details needed.

Good luck

Airshow

(edit: you have posted again while I was typing - will look now)

Airshow 416 WiFi Lounge Lizard

14 Years Ago

Tim,

Aaaaaagh namespacy XML! I really can't understand why some web architects insist on making things more complex than they need to be. (Not you but someone who came before). I once worked on a JSP site that started to go this way - I resigned.

Rant over .... I think I'm right in saying that everything I said above still applies. It's just harder for you to track things down and fix them.

You are clearly denied the possibility of simply inserting debug stuff on the page [ your onClick="alert('Pop-up'); ].

Unless you are running your own, private Apache/Tomcat, you shouldn't go in and hack rp.tld - it is probably used in other pages, which will most probably break - not good even in a development server. You will need to work with a copy of rp.tld.

I'm not sure I can help further as this type of coding is outside my experience. The error message mentions tomcat.catalina. Maybe the api will help.

Good luck

Airshow

Reply to this topic

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.

Tmanchester 0 Newbie Poster · Answer 1 · 2009-07-10T02:40:31+00:00

Certainly. From the jsp:

<rp:submit value="Add Bank Account" />

The submit tag is defined in a file we've cleverly named rp.tld:

<tag>
    <name>submit</name>
    <tag-class>com.rentpayment.tags.Submit</tag-class>
    <attribute>
      <name>value</name>
      <required>false</required>
      <rtexprvalue>true</rtexprvalue>
    </attribute>
    <attribute>
      <name>name</name>
      <required>false</required>
      <rtexprvalue>true</rtexprvalue>
    </attribute>
    <attribute>
      <name>align</name>
      <required>false</required>
      <rtexprvalue>true</rtexprvalue>
    </attribute>
    <attribute>
      <name>includeHtml</name>
      <required>false</required>
      <rtexprvalue>true</rtexprvalue>
    </attribute>
  </tag>

When I try to modify the submit tag so I can try to capture the click and enter actions like so:

<rp:submit value="Add Bank Account" onClick="alert('Pop-up');"/>

I get the following error:

2009-07-09 13:33:04,551 [http-80-Processor24] ERROR org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/].[jsp] - Servlet.service() for servlet jsp threw exception
org.apache.jasper.JasperException: /add_bank_account_001.jsp(163,4) Attribute onClick invalid for tag submit according to TLD

.

I hope you find this helpful.

Regards,

Tim

Tmanchester 0 Newbie Poster · Answer 2 · 2009-07-10T05:14:33+00:00

Thanks for the response Airshow. I took a cue from your comment about browsers behaving differently and discovered the following:
In Firefox, it didn't matter how you submitted. Both mouse-click and tab-enter on submit caused the following page to present all of the data expected. In IE a mouse-click caused the data to show as expected on the following page, however a tab-enter on submit brought you to the next page with the account data missing.

Oddly, the data was actually submitted in both cases as an examination of the db and navigating back to the page that displays account data shows the new account.

So after a brief examination of the flow:
1. add_bank_account_001.jsp
2. AddBankAccountHandler.java
3. property_accounts_001.jsp

I see that starting on add_bank_account_001.jsp, the new account info is sent in to AddBankAccountHandler where the new account is created in the db a list of accounts is populated into the request (as a list in an attribute called "Accounts") where it is then sent on to property_accounts_001.jsp and displayed (or not).

So if my only difference is in browsers, what in IE would cause the app to not populate or read the attribute "Accounts" correctly? I will do a little bit of stepping through code to see if the list is being generated as expected on the server side in both cases.

Anyway, after this particular line of thought we have probably exhausted this line of reasoning. I thank you for the brain power.

Regards,

Tim

Airshow 416 WiFi Lounge Lizard Team Colleague · Answer 3 · 2009-07-10T06:28:15+00:00

Tim,

The plot thickens.

What controls the flow? Is there a Struts layer? If so, the answer could lie therein though it's difficult to see exactly how if all data is submitted on all occasions.

Just a thought .... if you have multiple submit buttons (or even if you don't) then something server-side will test which button was pressed. It seems that the button variable is not being included in the POST under the circumstances you describe. I think it's worth checking to see if it's coming through (in both FF and IE). As I said I'm not particularly experienced with this architecture so I can't really suggest where to look but you seem ok with tracing things through.

Airshow

Airshow 416 WiFi Lounge Lizard Team Colleague · Answer 4 · 2009-07-10T07:03:55+00:00

Tim,

On a different tack .....

It's not wholly satisfactory solution but if you get desperate, then you could quite simply disable submission via tab-enter like this:

<FORM METHOD="POST" action="xxx.html">
	Name: <INPUT TYPE="TEXT"><BR>
	Address: <INPUT TYPE="TEXT"><BR>
	City: <INPUT TYPE="TEXT"><BR>
<INPUT TYPE="submit" Value="Ok" onKeyDown="if(event.keyCode==13) this.blur();">
<INPUT TYPE="reset" Value="Cancel">
</FORM>

With a little imagination you could make sure it only disables in IE.

And of couse you will need to attach the javascript differently because of the custom button.

Airshow

Airshow 416 WiFi Lounge Lizard Team Colleague · Answer 5 · 2009-07-10T07:50:06+00:00

Tim,

Found it! This thread

It's a bit hard to follow but essentially, the solution is to insert a hidden field into the form and test its presence/value(?) server-side to remove reliance on the submit button's value (which appears not to get submitted by IE as I thought might be the case).

The thread doesn't get into what to do if you have multiple submits (which is precisely why you would want to test which one stimulated the submit), but I guess that could be overcome. My demonstration above shows that an attached javascript handler will fire under both conditions (click and tab-enter), so if you have multiple submits, then get each of them to set the value of this new hidden field with something unique.

There's a bit of work for you to fix it but not severe in the overall scheme of things.

Airshow

Tmanchester 0 Newbie Poster · Answer 6 · 2009-07-10T22:45:10+00:00

Thanks for the article Airshow. Fortunately, I have a little extra time to diddle with this bug so I can give your suggesting a try this morning. Oh and for the record, we have a crappy home-brewed MVC app that we're using. I really want to rip the arms of the guy off who wrote this thing but he's not here anymore (the app is part of the reason for that).

Lots of good suggestions, I think I should have this licked today.

Best Regards,

Tim

Airshow 416 WiFi Lounge Lizard Team Colleague · Answer 7 · 2009-07-11T04:01:37+00:00

Hey Tim,

Yeah I guessed as much. You have my sympathy. Work on that last suggestion of mine first. I think it may be a winner.

Thinking about it, the smart way ahead is to transfer the "name" over from the submit button to the new hidden field such that (with luck and a following wind) nothing server side needs to change.

Very best of luck with it.

Airshow

Tmanchester 0 Newbie Poster · Answer 8 · 2009-07-11T04:36:07+00:00

Got it! The problem turned out to be the custom submit button that was being handled differently by IE vs Firefox. The joker who originally coded the thing put in javascript to handle both onClick and submit (it was the same script in either case). It appears that Firefox could tell that the same script was being called and threw one call out. IE would make 2 calls which would cause some interesting race conditions once they got to our server code.

Removing the onClick script from the button seems to be working.

Here's hoping we hire a good UI guy soon.

And thanks Airshow.

Regards,

Tim

Airshow 416 WiFi Lounge Lizard Team Colleague · Answer 9 · 2009-07-11T04:52:48+00:00

Tim,

Yikes that's serious sh*t. Well sussed, not easy. I hadn't even thought of that possibility.

Like you say, the guy was a joker.

Let's hope there's not too much more of the same.

Airshow

UI behavior

Recommended Answers Collapse Answers

All 12 Replies

Recommended Answers