Can you point to a test case and the file that has the code? Is this an older version of the ASP.NET framework? Is there an update? For reference this appears to be the same problem.

https://github.com/blueimp/jQuery-File-Upload/issues/968

We definitely need to know more about the circumstances. As I understand "use strict" it should only apply to jQuery's own function closure and nothing else.

You are right, but if MS ajax called from jQuery event so it's run in jQuery closure.

I user asp.net 4.0.

I'll prepare simple test case.

There is test case for this issue:

http://jsfiddle.net/4yFQ4/

Try click on button and you'll not see an error (just error of invalid post to server but ignore it, because there is no server side code can be running in jsfiddle).

But when you start typing in textbox, keypress event fired and call jQuery click on button, button call to postback function and you will see an error.

If you link jQuery file without "use strict", so everything will work fine without errors of strict mode.

There is a lot of junk in the repro case, I cleaned it up:

http://jsfiddle.net/4yFQ4/5/

The workaround is to fire native click so the stack doesn't go through jQuery:

http://jsfiddle.net/4yFQ4/6/

I don't think we should have to remove "use strict" in jQuery to make things like this work, if there is a workaround.

you know, there is just example that have native click event handler, but what to do if you have custom things?

not to use jQuery at all? how to work around you there is no native analogs....

what Microsoft says about new jQuery (I know that MS use jQuery in .Net 4.5), how new jQuery passed all tests in asp.net?

"use strict" is good when you test a library. but if everything is ok, no need write it to release file.

for example I use a plugin that can't run in "use strict", so I can't use jQuery for it?

I do not know the answer to hypothetical questions; if there are many cases where it can't be worked around then we'd need to figure out some other solution. For now the answer for your own code may be to use a local version of 1.9.0 with the "use strict" line removed, or just to stay with 1.8.3.

The danger in testing with "use strict" but removing it for production would be that the browser behavior DOES change and our testing would be in a different environment. So if we had to do that we might as well just remove the "use strict" entirely.

It seems like the main issue is that ASP.NET is using features unsupported by "use strict" and if you use ASP.NET then **none** of the code on your page can confidently be strict without risking this kind of problem.

That doPostBack code is crazy. It "knows" that it was triggered by an event and traces back up the stack to find the original event handler, then grabs the first arg which is the event object. For IE it doesn't have to do that since window.event is a global.

Ok, I understood you:)

May be you know good replacement for asp.net postback function?

There is no problem to replace any asp.net js framework function, but my skills are not enough for it.

By the way in IE this code running just fine. The problem in FF...

Interesting that Chrome works even though it's asked to walk the stack back through strict-mode code. IE doesn't need to do the walk, as I mentioned above. Either Firefox is throwing an error here when a warning would be sufficient, or it actually doesn't record the .callee in strict mode.

It's not just Firefox / .NET. I've been using https://github.com/eriwen/javascript-stacktrace to generate stack traces for debugging; it breaks in Chrome when I call it from code that's triggered by a jQuery event.

Looks like we'll need to remove the "use strict" and settle for having Uglify enforce the strictier rules.

@jphaas, why use the .callee approach in Chrome when it supports the error.stack property?

We could remove the "use strict" but I have the feeling it's all about old tools refusing to use proper approaches, am I wrong?

Asp.net 4.5 was released but still use old tools...

jQuery team need talk with Microsoft team about solution :)

buy the way, if you have rewritten _doPostback code so it not a big problem create a plugin that replace asp.net js framework core function.

Fix #13335. Remove "use strict".

Changeset: 7adee6c4da5c89e96b1532b6bd3faa1ee4bfdb2a

Fix #13335. Remove "use strict".

Changeset: 0e2977583c0455eda940a28b2499cad2cbf24ee4