This project is archived and is in readonly mode.

#601 ✓duplicate
Robb3h

IE7 Problem with extending forms

Reported by Robb3h | February 25th, 2009 @ 10:32 AM | in 1.3.0 rc2 (closed)

I've just come across a (what I think is) a bug in IE7 where it is not possible to extend (or select using $('id'), $$, getElements, getElement etc) a form which contains a field with the name "position". The offending html:

<input type="text" name="position" id="positionEdt" value="anything" />

As far as I can work out (though I am relatively new to js and dom stuff) is position is a element.styles property so I can't see why it would affect it here. In Firefox there is no problem, but in IE7 it generates the error "Line 1429, Object doesn't support this property or method" Which I assume is in the main mootools-core.js file (I'm using the uncompressed full one currently, version 1.2.1), followed by another error which says the same and points to the line in my javascript code which is:

alert($('contactForm'));

Changing the name attribute of the field fixes it, but it was annoying to track down. Sorry if this isn't really a bug and just my noobishness, but I felt I should at least submit it incase it was :)

Thanks for all your work on mootools! Love it.

Ps. Just realised I've posted this in the wrong version... not sure how to fix this as this is my first time on lighthouse, sorry!

Comments and changes to this ticket

  • Fábio M. Costa

    Fábio M. Costa February 25th, 2009 @ 05:52 PM

    Thanks for the report Robb3h. Looks like the same bug as the 'length' id (you can't have id="length"). Don't know how to fix this, you guys have any ideas? This seems like a javascript/IE7 problem, not fixable by mootools, right?

  • elado

    elado February 25th, 2009 @ 07:49 PM

    This happens because "position" is a method of MooTools and in IE you cannot assign a value to a property that is "occupied" by the browser (the input is a property of the form).

    Example:

    
    <script type="text/javascript">
    onload=function () {
    	f=1; // error!
    	var f=1; // works
    	f.x=1; // error!
    	delete f.x; // error!
    };
    </script>
    <form id="f" method="post" action="">
    <input type="text" name="x" id="x" value=""/>
    </form>
    

    I can't find a solution but at least you know this is the problem -- don't name elements with MooTools methods.

  • Rick Hopkins

    Rick Hopkins July 14th, 2009 @ 04:07 PM

    • Assigned user set to “Valerio”

    I just ran into this problem as well. It took me about 2 hours to figure out why I couldn't grab the form with $('formID'); Very annoying issue to try and debug. Thanks for posting the bug. Any word on a fix? My problem came in a form for entering new employees so instead of calling the field "position" I called it "jobtitle" and problem was solved.

  • Tommy Valand

    Tommy Valand July 20th, 2009 @ 02:06 PM

    • Assigned user cleared.

    I have a form with a field named "show". Element has a method named show. When Mootools tries to add the show-method to the form element(in Document.id), IE refuses to accept this (Object doesn't support...).

    As I don't need the show-method, I deleted it from Element.Prototype (delete Element.Prototype.show). Then everything works great.

    The reason for all of the above problems is that Mootools modifies the native Element prototype instead of wrapping it (like jQuery, ExtJS and YUI does). From what I think I've read earlier, this isn't something that's going to change.

  • Tommy Valand

    Tommy Valand July 20th, 2009 @ 02:34 PM

    I spoke too soon. Removing Element.Prototype.show messes up Fx.Reveal, and a lot of other stuff.

    My second workaround is rewriting Document.id:
    Document.implement({

    id: (function(){
        var types = {
            string: function(id, nocash, doc){
                id = doc.getElementById(id);
                return (id) ? types.element(id, nocash) : null;
            },
    
            element: function(el, nocash){
                $uid(el);
                if (!nocash && !el.$family && !(/^object|embed$/i).test(el.tagName)){
                    var proto = Element.Prototype;
                    var p;
                    if( Browser.Engine.trident ){
                        for (p in proto) {
                            if ( !el[p] ) { el[p] = proto[p]; }
                        }
                    } else {
                        for (p in proto) {
                            el[p] = proto[p];
                        }
                    }                   
                }
                return el;
            },
    
            object: function(obj, nocash, doc){
                if (obj.toElement) { return types.element(obj.toElement(doc), nocash); }
                return null;
            }
    
        };
    
        types.textnode = types.whitespace = types.window = types.document = $arguments(0);
    
        return function(el, nocash, doc){
            if (el && el.$family && el.uid) { return el; }
            var type = $type(el);
            return (types[type]) ? types[type](el, nocash, doc || document) : null;
        };
    
    })()
    

    });

    The above rewrite only affects IE users (Browser.Engine.trident). It doesn't try to overwrite properties on the element if they're already defined. A lot less intrusive than my first rewrite, but could still be confusing to work with.

  • Scott Kyle

    Scott Kyle July 20th, 2009 @ 04:07 PM

    • Assigned user set to “Valerio”

    I outlined this solution on issue #679 (which is a duplicate of this), but am not aware of all the ramifications of using this. It may cause some very undesirable gotchas. I'm gonna pass this to Valerio to see what his thoughts on this solution are.

  • Scott Kyle

    Scott Kyle August 9th, 2009 @ 09:17 PM

    This issue is fixed in MooTools 2.0. Thanks.

  • fcartegnie

    fcartegnie December 14th, 2009 @ 10:22 PM

    • Tag changed from 1.2.1, dollar-dollar, ie7, selector to 1, dollar-dollar, ie7, selector

    Just commenting

    Same problems with form containing:


  • Christoph Pojer

    Christoph Pojer December 18th, 2009 @ 12:07 AM

    • State changed from “new” to “resolved”

    As noted above this is fixed in MooTools 2.0

  • Christoph Pojer

    Christoph Pojer December 18th, 2009 @ 12:21 AM

    • Milestone changed from 2.0 to 1.3.0 rc2
    • State changed from “resolved” to “open”

    Should be fixed in 1.3 too (needs specs)

  • Fábio M. Costa

    Fábio M. Costa April 4th, 2010 @ 11:32 PM

    • State changed from “open” to “duplicate”

    ok duplicate of #679, there are enough info there.

  • Rogan Josh

    Rogan Josh May 26th, 2010 @ 07:24 AM

    • Assigned user cleared.

    Just gave me 3 hours of grief in IE8 as well, thanks for fixing in 1.3 & 2.0

    Love mootools

    hate IE...

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

Shared Ticket Bins

Referenced by

Pages