• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Page can't find form certain inputs

 
Ranch Hand
Posts: 66
3
Netbeans IDE Notepad Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi!

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[2].<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"/>



So... It's definitely *in there*; whatever method Javascript uses to find it by navigating the DOM is just failing.

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?
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The notation you are using to find the elements is about two decades out of date. There is a whole API to find elements by id, by tag name, or by other selector methods.

And then, of course, there's jQuery which makes finding elements almost trivial.

Any reason you're not using jQuery or any of the modern API?

E.g.: document,querySelector()
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oh wait... you are using jQuery (your last two examples).

So why are you using document.forms rather than jQuery which is apparently already in use?  
 
Alex Lieb
Ranch Hand
Posts: 66
3
Netbeans IDE Notepad Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Two reasons!

First, one of our shop's general coding style guidelines is to try to use the most basic, native, non-library-aided methodology possible in any given scenario. If there's no strict need to involve X Y or Z thing, tool, or utility, don't use that thing. Prefer document.forms.country over $("input[name='country']"). Almost all of the JavaScript on our site uses old notation and methodology. We have jQuery, but we only added it to our project because there were certain styling things we wanted to do that we could not do without using jQuery.

Second, I don't see a reason this code shouldn't work as is, and I don't want to just fix it by going around it. I'm afraid if I do that, since I do not understand the bug, it'll continue to crop up in unexpected ways in the future. Also this is the most JavaScript-intensive page on our site; about 2070 lines of JS go into making this page work, and if I fixed this by just using jQuery, I would have to rewrite almost all of that. The way this code is failing tells me that there's likely some solution that would live at the page-scope or request-scope level, and I think it'd be easier in the short term and better in the long term to find that solution.
 
Alex Lieb
Ranch Hand
Posts: 66
3
Netbeans IDE Notepad Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Marking resolved because in spite of how frustrating and dissatisfying the resolution is, I suppose it is now resolved...
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic