Skip to main content

Bug Tracker

Side navigation

#13335 closed bug (fixed)

Opened January 27, 2013 07:22PM UTC

Closed February 01, 2013 10:25PM UTC

Last modified February 01, 2013 10:29PM UTC

"use strict"; break asp.net ajax postacks in FF

Reported by: psyafter Owned by: dmethvin
Priority: blocker Milestone: 1.9.1
Component: build Version: 1.9.0
Keywords: Cc:
Blocked by: Blocking:
Description

"use strict" mode in jQuery 1.9.0 break asp.net ajax postbacks in FF.

Microsoft js framework can't work in "use strict" mode because of this line

while (caller.arguments.callee.caller && --recursionLimit) {

FF failed with error:

TypeError: access to strict mode caller function is censored

If I remove "use strict" in jQuery file so asp.net js framework begin posts without any error.

Attachments (0)
Change History (19)

Changed January 27, 2013 07:34PM UTC by dmethvin comment:1

owner: → psyafter
status: newpending

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

Changed January 27, 2013 07:38PM UTC by dmethvin comment:2

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.

Changed January 28, 2013 07:15AM UTC by psyafter comment:3

status: pendingnew

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.

Changed January 28, 2013 08:12AM UTC by psyafter comment:4

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.

Changed January 28, 2013 03:03PM UTC by dmethvin comment:5

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.

Changed January 28, 2013 03:11PM UTC by psyafter comment:6

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?

Changed January 28, 2013 03:14PM UTC by psyafter comment:7

"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?

Changed January 28, 2013 03:23PM UTC by dmethvin comment:8

_comment0: 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.1359386662330086

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.

Changed January 28, 2013 04:51PM UTC by psyafter comment:9

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...

Changed January 28, 2013 05:02PM UTC by dmethvin comment:10

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.

Changed January 30, 2013 06:43PM UTC by jphaas@gmail.com comment:11

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.

Changed January 30, 2013 07:59PM UTC by dmethvin comment:12

component: unfiledbuild
owner: psyafterdmethvin
priority: undecidedblocker
status: newassigned

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

Changed January 30, 2013 07:59PM UTC by dmethvin comment:13

milestone: None1.9.1

Changed January 31, 2013 03:36PM UTC by dmethvin comment:14

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

Changed January 31, 2013 04:00PM UTC by jaubourg comment:15

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?

Changed January 31, 2013 04:13PM UTC by anonymous comment:16

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

jQuery team need talk with Microsoft team about solution :)

Changed January 31, 2013 04:18PM UTC by anonymous comment:17

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.

Changed February 01, 2013 10:25PM UTC by Dave Methvin comment:18

resolution: → fixed
status: assignedclosed

Fix #13335. Remove "use strict".

Changeset: 7adee6c4da5c89e96b1532b6bd3faa1ee4bfdb2a

Changed February 01, 2013 10:29PM UTC by Dave Methvin comment:19

Fix #13335. Remove "use strict".

Changeset: 0e2977583c0455eda940a28b2499cad2cbf24ee4