We Keep Coding

HTML Input only works at front of input field

I have a web page with an odd behavior on part of it.
On most of the page, the input tags work just the way one would expect.
Here's an input tag I put in to test:
<input name="vanilla1" value="vanilla" />
In one part of the page, I can click on the field to edit it, but only at the front of the field. So, if the input tag had a value of "vanilla", I could click in front of the "v" and start typing or deleting. But it won't let me click between the two "l" characters and start typing.
It's not easy to just post a full working sample, I would have to retype by hand a lot of code.
If I wanted to get that behavior I don't have a clue of how to do it.
Any ideas of what to look for that might cause this?
It's obviously not disabled or readonly because I can edit it.
When I inspect the problem input tags in the IE DOM explorer, they don't look any different from the input tags that work as expected.
There's javascript, html, angularJS and dojo, plus the esri gis api css libraries in the technical mix.
A few more observations:
In IE, when I click on a working input tag that already has a value in it, I get a little X show up on the far right of the input box. If I click on the X the field is blanked out. On my problem input tags, when I click on them, I get the X but clicking the X does not work. So I appear to be accessing the right object.
When I inspect the object, everything looks normal. No javascript events attached, it's not read only or disabled.

Isn't it like covered by another node or something like that?
Did you check it in all browsers or only in IE?
Try to open Chrome DevTools and click the "Select an element in the page to inspect it" (top left corner of the DevTools window, CTRL + Shift + C shortcut on Windows) and hover over that input. See if there's possibly any element that may cover it. If there's - voila! Remove that overlay and you're good to go. If not - I don't have any ideas for now.

Chrome Auto-fill is executing after my JS

In Chrome, I have created form input elements that has a label, when focused, float above the input field. This works and executes perfectly.
When I use the chrome autofill for the username and password, the browser populates the input field with the yellow prefilled text. The issue I am having is the label JS does not execute and float to the upper right when the yellow prefilled text is visible. It does auto-correct the issue if you click anywhere on the page. Any thoughts or solutions? I do need the autocomplete feature to be set.

When Chrome autofills an input, it won't trigger the :focus state that your CSS currently relies on. Unfortunately, no such pseudo-selector exists in CSS for detecting whether an input is filled or not (learn more here).
Your best option is using jQuery to detect whether each of your inputs has a value and add a class if true. See the example here. Then revise your animation effect so that it applies to input.has-data-class, for example.

Textarea Autocomplete

Autocomplete="off" on textarea fields doesn't seem to work as it does with input fields. I couldn't find anything about this on Google. Is there a difference?
Specifically, I have a page that has half normal input fields, and the other half dynimically generated via javascript. When I navigate away from the page and then navigate back, the text that was in the dynamically generated fields overwrites that which is in the normal fields. This only happens when I navigate away and then click back. If I just refresh the page, it doesn't happen. Autocomplete="false" solved this problem for input fields, but it did not for textareas.

The autocomplete attribute or property is limited to input elements, both according to Microsoft description of the feature and according to the HTML5 draft description proposed to standardize the feature. So you should expect browsers to ignore it for other elements, including textarea.
Apparently, autocomplete is not the real question, just an assumed approach, which is a wrong one. But the real problem was not really described.

Clear button for form input field using JQuery and JQTouch

I have a site built using JQTouch and want to add the little cross
buttons within text input fields to clear out text on press.
I've tried emulating Google's technique from their google.com iPhone
site. Also I've read about that approach over here
little 'x' in textfield input on the iphone in mobileSafari?...
I have this partially working. But whether and when a press on the
cross button is registered seems unreliable.
I've created minimal code to test this:
with JQTouch -
http://hogtownconsulting.com/clearquery/index.html
without JQTouch (or any other JS libraries) -
http://hogtownconsulting.com/clearquery/index-no-js.html
I'm not certain that it's an interaction with the JQTouch library
that's causing these problems. But the version without JQTouch does seem more responsive to taps on the cross button. Any suggestions on how I can get this feature working
properly would be much appreciated. Thank you, Patrick

You get that little X automatically if you name your input type = search.
<input type=search name=s>
This article will help you plenty.
CSS Tricks for WebKit
If you don't want that input to be a type = search, then you will have to fake it out a bit.
1. create a div and round it using css.
2. put your input in there, and remove webkit decoration, shading etc.
3. put a SPAN with your X image in to the right of the input. add an onclick to that image which clears your field.
<div><input type="text" id="thing"/><span onclick="clrField();"><img src="x.gif"/></span></div>

Safari Javascript Issue

I am currently working on a Javascript program for my company (Leader Technologies) that is used to register products for Logitech. The URL for that is :
http://wwwtest.onlineregister.com/logitechreg/
My program looks totally fine on everything single web browser (including IE 6) that I have tried except Safari 4. On Safari 4, after a location, language and product category have been selected, when the actual product menu is clicked (id=WHPR), the div responsible for displaying the product is shown, but the drop-down selections are still visible. On all other browsers, the drop-down and the possible selections inside it in hidden (which is the intended behavior.)
Directly, my question is can I hid this drop-down successfully in Safari 4 WITHOUT completely emptying out the drop down and then repopulating it with only the selected value? I would rather not do this if at all possible, but if it's the only way to accomplish my goal then I can change the site additionally.
I believe the problem is where I set the listeners on the <select>:
<select id="WHPR" class="ui-formulate-ignore" style="width: 280px; visibility: visible;" onchange="whprChanged(this);" onfocus="displaySelector(form, document.getElementById('WHPR')); document.getElementById('imageHolder').focus(); this.blur();" name="WHPR">
Thank you all very much for taking the time to help me. I really appreciate all the help available on this site.
-Brian J. Stinar-

Not to pick on your style, but attaching listeners inline like you're doing is not very clean. Why not take advantage of jQuery's ability to deal with any browser discrepancies? The page you refer to is already loading it.
See http://docs.jquery.com/Events/bind

I think it's some kind of a bug in Safari - for example if you do .focus() nof for the DIV but for another input element like a textfield, then after clicking the selectbox both would have the focus (or actually, the focus would stay in the selectbox and the textbox would only seem to have the focus by having thicker border than usual).
Anyhow quick and dirty methot to achieve the goal would be removing the selectbox from the page (display: none) and then bringing it back (display:inline).
replace the this.blur() with the following command
this.style.cssText='display:none';var select = this; window.setTimeout(function(){select.style.cssText='display:inline';},1);
If you don't use a delay then it doesn't work - the removal and retrieval of the element need to be in different scopes.