I have a page that works just fine on Firefox and Chrome, but under certain circumstances it fails in IE.
How it fails:
When calling document.forms.<fieldName>, certain fields are returned as undefined. Not all of them, just some of them. Obviously they must have *something* in common, but so far I haven't been able to find a link. There's no correlation relating to load order, which JSP they belong to (This page is built using multiple includes), whether they're hidden/shown, id, name, value, or input type. However it is the same fields on every load.
I know the fields *are* present in the page though. If I run the following things in the console, for example, I would get these responses:
Say there's an input in the third page form and it's the... What the heck, the fifth field on the page, like this: <input type="hidden" name="country" value="Canada"/>
When it fails:
Only for certain machines running IE11, only on this particular page, and only when trying to access the site running on our test server. So when I try to go to <ourtestserver>.com/blahpage, it fails; when I try to go to localhost:8080/blahpage, or <anyLocalAddress>:8080/blahpage, it works. Http vs https makes no difference. And I've tried this on uh.... At least 9 machines so far. It's failing for 2 of those machines, and is working on the other 7. So I'm really lost at this point, but somehow this bug has to lie at the cross section of these 3 factors:
The specific version of IE11 installed on one machine vs another.
Some difference between responses received from our test server and from a local host.
The page itself vs other pages on our site.
Has anyone else seen anything like this before, or can anyone offer any advice, hints, or at this point even complete guesses as to why this could be happening?
Alex Lieb wrote:Prefer document.forms.country over $("input[name='country']").
Except you left out the fact that document.forms is a list for which you must use a positional index. This makes the code fragile as any change to the structure of the page may break the code. In the case of the jQuery equivalent (where you should be prefixing the selector with a reference to the containing form) or the modern native equivalent, the code continues to work as long as the name of the element doesn't change.
If jQuery is already loaded for other purposes it makes no sense to me not to leverage it for more robust code.