I agree the other report seems similar, but it also lacked enough information for us to do anything. Can you make a test case so we can see the conditions when it fails? Use jsFiddle.net to create your test case. Be sure to test against the jQuery git("edge") version to ensure the issue still exists. To get you started, use this boilerplate: http://jsfiddle.net/FrKyN/. Open the link and click to "Fork" (in the top menu) to get started.

http://jqueryui.com/demos/autocomplete/default.html

This demo is promised to fail in ie7.

I'm sorry, but your promise has fallen short and that demo works flawlessly for me in IE7, which is fully expected as nobody else has reported such a problem with autocomplete. Do you have any browser extensions installed that might be causing issues? Are you able to reproduce this on other machines?

Replying to [comment:3 scott.gonzalez]:

I'm sorry, but your promise has fallen short and that demo works flawlessly for me in IE7, which is fully expected as nobody else has reported such a problem with autocomplete. Do you have any browser extensions installed that might be causing issues? Are you able to reproduce this on other machines?

I tested it on my IE10 with IE7 mode, console showed "Member not found" error. But it works fine on IE9's IE7 mode. So maybe it's an IE10's-IE7-mode-specific bug?

I see this same problem when I use (1) Windows 8, (2) Browser Mode: IE10,

(3)Document Mode: IE7 standards. This problem also fails on jQuery ui demo site here: http://jqueryui.com/demos/autocomplete/

My work around is to put a try/catch around the line "return ( ret.nodeValue = value + "" );" or do the following:

set: function( elem, value, name ) {
     if (navigator.userAgent.toLowerCase().indexOf('msie') != -1 && document.documentMode <= 7) {
          elem.setAttribute(name, value);
	  return elem.getAttributeNode(name);
     } else {
          // Set the existing or create a new attribute node
	  var ret = elem.getAttributeNode( name );
	  if ( !ret ) {
	       ret = document.createAttribute( name );
	       elem.setAttributeNode( ret );
	  }
          return ( ret.nodeValue = value + "" );
     }
}

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

I can confirm that I get the same problem. Windows 8, IE10 with browser mode IE7. Also on a form with auto complete turned off.

I am also hitting the same issue with IE10 Release Preview on Windows 7, with IE10 set to Browser mode: IE7 and Document Mode: IE7 standards.

This does not repro in standalone IE7, or IE9 with Browser mode: IE7 and Document Mode: IE7 standards, so possibly an IE10 related bug?

I still cannot repro, which makes me think this may be due to some browser add-on such as a form filler. Let's compare screen shots. Here is mine showing several different browser/document modes with no errors, and the add-ons that were installed:

• http://i.imgur.com/wylr2.png
• http://i.imgur.com/Pxh2X.png
• http://i.imgur.com/drohq.png

This happens when IE 10 is set to IE7 Browser Mode and Document Mode IE7 standards.

The issue occurs when using the jQuery Validation Plugin (I'm using version 1.10.0).

The plugin tries to set a 'novalidate' attribute on the form tag. This fails.

Same issue for me, Windows 8, IE10 in IE7 mode.

Same thing here. Apparently it's something to do with Win8 and IE10's IE7 compat mode. I got it to work by changing the set to the following:

            set: function (elem, value, name) {
                // Set the existing or create a new attribute node
                var ret = elem.getAttributeNode(name);
                if (!ret) {
                    ret = document.createAttribute(name);
                    elem.setAttributeNode(ret);
                }
                elem.setAttribute(name, value + "");
                return (ret.value);
            }

I'm not sure as to the ramifications of this change, but for now it appears to be working.

jQuery 1.8.3

I'm seeing exactly the same thing. How do we get this bug to get re-opened?

Replying to [comment:15 danmiser@…]:

I'm seeing exactly the same thing. How do we get this bug to get re-opened?

Provide a complete reduced test case on jsFiddle/jsbin/etc. against jQuery 1.8.3 and/or edge to help us assess the issue.

I recommend forking from this boilerplate: http://jsfiddle.net/FrKyN/

New ticket created @ http://bugs.jquery.com/ticket/13023

#13023 is a duplicate of this ticket.

http://jsfiddle.net/xPc3p/2/

Can you post a link to your Microsoft report at connect.microsoft.com? I see the error but don't see that jQuery is doing anything wrong here.

Simpler repo without the try/catch, whose presence seems to hose the debugger:

http://jsfiddle.net/xPc3p/4/

Screen shot of the error and state: http://i.imgur.com/IyQ8Z.png

Bug is still reproduced but no one cares.

Also, the obvious and easy fix:

// Add novalidate tag if HTML5.

if (!$.browser.msie || $.browser.version > 7) {

this.attr('novalidate', 'novalidate');

}

Code with correct formatting

// Add novalidate tag if HTML5.
if (!$.browser.msie || $.browser.version > 7) {
	this.attr('novalidate', 'novalidate');
}

jQuery no longer supports jQuery.browser in the core library.

Please go to the Microsoft bug tracker and vote up this bug:

https://connect.microsoft.com/IE/feedback/details/774078

You may need to register at the site with a Live ID.

Do not post "me toos" here.

I'm closing this pending investigation by Microsoft. Nobody else has voted up the ticket there. May be reopened based on their response. Don't post here, register at the Microsoft site and upvote the ticket or add more information.

#12844 is a duplicate of this ticket.

anonymous: http://bugs.jquery.com/ticket/12577#comment:28

do not post "me toos" here. Please go to the Microsoft bug tracker and vote up this bug: https://connect.microsoft.com/IE/feedback/details/774078 You may need to register at the site with a Live ID.

having signed in with my Live ID, that Microsoft link leads to an error page. where to turn now? I'm ''not'' using compatibility mode, but IE7 through a virtual machine

go to https://connect.microsoft.com/, search for IE10, click join, create profile, ignore xml error, repeat from top, come back here and click on link for issue. (worked for me)

FYI, Microsoft today closed this bug wontfix for IE10, I assume that means it won't get any love until IE11.

At present the best workaround is to not run IE10 in compatibility view. Make sure you have a valid HTML5 doctype on the document.

Hi guys,

I'm not sure the best way to test for IE7 compatibility is via IE7 mode in IE10. There have been many occasions where I do this, and something breaks in IE10 set to IE7 mode, but works perfectly in IE8 set to IE7 mode.

I suggest you test for IE7 compatibility using IE7 if possible. Set up a virtual machine or something. It's not that hard to do, and if you're actually developing for IE7 (God forbid) then you should be testing in IE7.

In any case, I'm getting this error as well in one of my projects, and I'm running IE8 in IE7 mode on one of my virtual machines.

This is frustrating - clearly IE7 mode should match IE7 proper and its no longer doing that.. But having to keep IE7 and IE10 installed in different virtual machines is super irritating to developers...

Got the same thing happening, windows 7, ie10 in ie7 browser and document mode.

Still happening

The workaround that I know is to not run IE10 in IE7 mode. If you can't do that then work out a patch or propose a solution and let us know. Adding vague "still happens" comments will just make it harder to see progress here.

Hi,

I was stuck with this for a couple of days.

My problem had to do with qTip trying to set attribuets with names like "aria-something" to an HTML element in IE10 wile on compatiblity mode (IE10 without compatiblity mode works just fine)

I am using jQuery 1.7.1 and updating to the latest jQuery library is just too much work and involves too much testing!

So my workaround for this problem :

		set: function( elem, value, name ) {
			// BUG related to ie10 compatibility mode not possible to set aria-parameters
			// The following problems were in Asynja: qtip didn't work, couldn't save patients by clicking save button and probably more.
			if (name.substring(0,4) == 'aria') {
				return;
			}
			// Set the existing or create a new attribute node
			var ret = elem.getAttributeNode( name );
			if ( !ret ) {
				ret = document.createAttribute( name );
				elem.setAttributeNode( ret );
			}
			return ( ret.nodeValue = value + "" );

		}

This way the "aria-" attributes will be ignored, I am not sure of what the sideeffects of this are, but so far I have not noticed any problem in my web-app.

Hope you find it helpful.

@dmethvin - the MS link you provided to upvote is broken. Would you mind to provide a new one? I'm also seeing this same error when trying to set the attribute 'aria-autocomplete': 'list' on an anchor element (again using IE10 in IE7 browser & document mode). Setting up another machine with IE7 is not ideal (or feasible for some of us). If it is not a jquery bug as you stated, is there a simple workaround we can implement such as some of the ones suggested above? No ones blessed them yet.

Replying to [comment:28 dmethvin]:

Please go to the Microsoft bug tracker and vote up this bug: https://connect.microsoft.com/IE/feedback/details/774078 You may need to register at the site with a Live ID. Do not post "me toos" here.

I found a workaround for getting this error when one of my plugins (selectmenu) is attempting to set the value ''''aria-autocomplete': 'list'''' (and I have read it also repros for a few other aria-* attributes (but not all).

The workaround is to apply the problematic attribute ('aria-autocomplete': 'list' in my case) using the .prop method instead of .attr. Seems to work, although I just tried this and not sure of any side effects yet. So far so good though.

Instead of doing this

var ac = $('<a/>', {'aria-autocomplete': 'list'});

I ended up doing this:

var ac = $('<a/>');
ac.prop('aria-autocomplete', 'list');

I found a workaround for getting this error when one of my plugins (selectmenu) is attempting to set the value ''''aria-autocomplete': 'list'''' (and I have read it also repros for a few other aria-* attributes (but not all).

The workaround is to apply the problematic attribute ('aria-autocomplete': 'list' in my case) using the .prop method instead of .attr. Seems to work, although I just tried this and not sure of any side effects yet. So far so good though.

Instead of doing this

var ac = $('<a/>', {'aria-autocomplete': 'list'});

I ended up doing this:

var ac = $('<a/>');
ac.prop('aria-autocomplete', 'list');

Following the advice of http://msdn.microsoft.com/en-us/library/windows/desktop/ms764615(v=vs.85).aspx

"You can set the value by calling the setAttribute method of the element object."

Change the offending line

ret.value = value += "";

to:

elem.setAttribute(name, value += "");

I was getting this error using Kendo UI and this fix works perfectly! Thank you so much!

Replying to [comment:50 Andre P.]:

Following the advice of http://msdn.microsoft.com/en-us/library/windows/desktop/ms764615(v=vs.85).aspx "You can set the value by calling the setAttribute method of the element object." Change the offending line ret.value = value += ""; to: elem.setAttribute(name, value += "");

Replying to [comment:47 johnrissone@…]:

The link is not broken. If you cannot see it, you'll need to register with the site and join the IE Feedback Program. Earlier comments make it seem like you only need to register.

@dmethvin - the MS link you provided to upvote is broken. Would you mind to provide a new one? I'm also seeing this same error when trying to set the attribute 'aria-autocomplete': 'list' on an anchor element (again using IE10 in IE7 browser & document mode). Setting up another machine with IE7 is not ideal (or feasible for some of us). If it is not a jquery bug as you stated, is there a simple workaround we can implement such as some of the ones suggested above? No ones blessed them yet. Replying to [comment:28 dmethvin]: > Please go to the Microsoft bug tracker and vote up this bug: > https://connect.microsoft.com/IE/feedback/details/774078 > You may need to register at the site with a Live ID. > > Do not post "me toos" here.

Just so I understand this correctly: there seems to be some reluctance on behalf of the jquery project to incorporate a fix that would allow it to work correctly even in this strange configuration of IE 10 masquerading as IE7.

Why exactly is that the case? Do you generally not want to support this mode of working? I sure as hell would like to use this mode to debug issues that I can reproduce there when they happen in a real IE7, as it's a much more pleasurable experience to debug in IE10 than it is in IE7.

And this just failed me because of this bug cropping up. :-(

It seems like it's not that big a deal to have some feature detection here that uses the recommended workaround of using setAttribute instead of the attibute node and setting the value on it.

So what am I overlooking?

Now how do I get notifications for this issue without posting a comment?

I would like to add that this is our current workaround - not sure what would be required to make this a patch to query.

#!js
if ($('html').hasClass('lt-ie8') && $('html')[0].getAttribute) {
	var ie10MasksAsiE7GetAttributeNodeWorkaround = {
		set: function( elem, value, name ) {
			elem.setAttribute(name, value);
		}
	}
	$.attrHooks.placeholder = ie10MasksAsiE7GetAttributeNodeWorkaround;
}

We have the problem with the placeholder attribute, for your project you probably need to expand this to the attributes that break for you.

I found a workaround that fixed this bug for me. Put the following META tag in your HTML header, it makes sure to use the latest version of the document mode even when IE7 is manually set by the user in IE10.

<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" />

I'd like to point out the workaround with the meta tag doesn't actually do anything. If you are emulating using Developer Tools, you can manually change to IE 7 Standards mode, which is really how I want to be testing anyway.

#14219 is a duplicate of this ticket.

For the error with the jQuery Validation plug-in, I have posted a fix on their issue site:

https://github.com/jzaefferer/jquery-validation/issues/845

I'm hoping they incorporate it as part of the plug-in soon.

This issue is still exists with IE10 with document mode is IE7

IE working in any document/compatibility mode is just that - a compatibility layer. IE 10 does *not* ship with rendering and javascript engines of previous versions of Internet Explorer. IE 10 in IE 7 mode is *not* IE 7. It's IE 10 with an emulator layer that can only try to reproduce results you would expect from an old version of the browser.

There are many things that will work differently than in true IE 7. Writing javascript that works properly in an emulator layer that none of your users will ever use is a waste of time. More than that, guess what? Something that you manage to make work in IE 10 with IE 7 document/compatibility mode *may not work the same way in real IE 7*. If you want to test your pages against old IE, you need to actually run old IE (what I do: virtual machines).

…I wouldn't disagree with that, but it sure as hell isn't a very pragmatic position. IE10's IE7 emulation layer is much easier to jump in and out of, which can be helpful to keep code on track before jumping into real IE7 for proper testing. This bug breaks that workflow.

Is it really such a complicated fix to even be worth the time spent resisting the community?

I agree it wouldn't be worth spending a lot of time on this… but judging from the responses, it seems like this is being blocked on principle?

Replying to [comment:65 nate]:

If you want to test your pages against old IE, you need to actually run old IE (what I do: virtual machines).

I work on a third-party JS library that runs on sites where the site is forcibly set to be in IE7 compatibility mode for all IE10 users; this isn't an issue simply of developers who want to experience the joys of IE7 in IE10. That said, I completely understand why the project hasn't been able to embrace any of the proposed solutions, because they create problems when it comes to supporting "real" IE7.

Replying to [comment:64 anonymous]:

Replying to [comment:63 Sandeep Goyal]: > This issue is still exists with IE10 with document mode is IE7 exactly, i'm using jquery-1.10.2 + jquery-migrate-1.2.1 on win8 IE10 with document mode is IE7, this error still appear

confirm same issue with IE10 in IE7 mode with aria- attributes.

jquery-1.11.0-beta1.js and jquery-migrate-1.2.1 doesn't help to resolve problem.

I have question to jQuery core team:

why everyone except you are trying to resolve this problem?

Is it so hard to fix it with jQuery version, which must support all IE?

Some patches written above help me to resolve problem, but i prefer do not change jQuery core by myself.

Backbone team modified jQuery v.1.8.3 based on solution from this ticket.

Why jQuery team can't do same?

I've noticed a similar issue (I'm guessing related with aria-orientation);

Can be easily reproduced in IE 11 compatibility mode;

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <link href="~/css/ui-lightness/jquery-ui-1.10.4.custom.css" rel="stylesheet" type="text/css"/>

    <script src="js/jquery-1.10.2.js"></script>
    <script src="js/jquery-ui-1.10.4.custom.js"></script>

    <title>test</title>
</head>
<body>
    <div id="test"></div>
    <script>
        $(function () {
            $("#test").attr("aria-orientation", "horizontal");
        });
    </script>

</body>
</html>

Gives me the following error:

SCRIPT3: Member not found.
File: jquery-1.10.2.js, Line: 4571, Column: 4

I don't typically use compatibility mode but I use it for testing. Hopefully this gets fixed rather then waiting for a Microsoft patch, which it seems is never coming.

#15250 is a duplicate of this ticket.

I recommend the jQuery team to fix this issue because obviously microsoft doesn't care about that bug. A bug that exist 2 years in various versions and also in the newest DEV Channel of IE. I see no chance to get this fixed by microsoft.