Bug Tracker

Opened 6 years ago

Closed 6 years ago

Last modified 5 years ago

#14123 closed bug (notabug)

JavaScript errors just by including jQuery 2.0.2 in WinJS app

Reported by: thomas.mckearney@… Owned by:
Priority: undecided Milestone: None
Component: unfiled Version: 2.0.2
Keywords: Cc:
Blocked by: Blocking:

Description

It's my understanding that jQuery 2.0+ is supposed to work fine in WinJS, and it seems to, but there are multiple errors thrown just by including the file in a WinJS app.

I have example code here: https://github.com/tommck/jQueryBugTest/

But, to replicate, run Visual Studio 2012, create a "Blank App" under the JavaScript "Windows Store" section. Then install version 2.0.2 of the jQuery NuGet package. Add a reference to jquery in the "default.html" file and run the app. There are errors reported to the JavaScript Console. If you have "break on throw" set for exceptions in JavaScript, it will stop at least twice.

Here are the error messages: SCRIPT5022: Exception was thrown at line 1571, column 4 in ms-appx://c33865be-41fa-45ec-b8f3-4d25e60ad0f3/Scripts/jquery-2.0.2.js 0x800a139e - JavaScript runtime error: SyntaxError

SCRIPT5022: Exception was thrown at line 1588, column 4 in ms-appx://c33865be-41fa-45ec-b8f3-4d25e60ad0f3/Scripts/jquery-2.0.2.js 0x800a139e - JavaScript runtime error: SyntaxError

NOTE: This is just from including and not using jQuery at all. I have experienced other errors from using jQuery too

Change History (16)

comment:1 Changed 6 years ago by anonymous

Just mentioning that I couldn't use jsFiddle because of the WinJS nature of the problem. Thanks in advance for any time you guys spend on this.

Tom

comment:2 Changed 6 years ago by dmethvin

Resolution: notabug
Status: newclosed

If you have "break on throw" set for exceptions in JavaScript, it will stop at least twice.

Don't do that. We throw and catch exceptions inside jQuery itself. Only break on uncaught exceptions.

comment:3 Changed 6 years ago by anonymous

Wow.. well, I write my software so that it won't have unhandled exceptions (catching at the top level at least), so running with only that really handicaps debugging ability.

I guess there are situations you can't detect without exception throw? That sucks.

comment:4 Changed 6 years ago by dmethvin

well, I write my software so that it won't have unhandled exceptions

jQuery doesn't have unhandled exceptions either. You're asking VS to break on throw, which includes handled ones. If the program is expecting to catch an exception and catches it, that's not an error. We need to be able to do that.

If you have a top-level error handler, break on unhandled exceptions only and put a breakpoint inside the top-level catch.

comment:5 Changed 6 years ago by anonymous

I understand how to debug around this, but it's much easier to debug an exception at the point it's thrown, rather than multiple levels up the call stack, especially when it's something obscure. That is what makes "break on throw" so useful.

Since most developers strive hard not to use exceptions for logic flow, I have not run into this in any other JavaScript library or any of my own code. I only run into it with jQuery.

If that's not a priority for you guys, I'm going to try to get the Visual Studio team to allow us to do file-based decisions on thrown exceptions in the debugger, since that will still allow me a better debugging experience outside of jQuery.

comment:6 Changed 6 years ago by timmywil

it's much easier to debug an exception at the point it's thrown

Breaking on unhandled exceptions still breaks on the exception.

Since most developers strive hard not to use exceptions for logic flow, I have not run into this in any other JavaScript library or any of my own code.

When we expect a browser to throw an error and it doesn't, that is a browser bug. Do you have another way to detect something like that?

comment:7 Changed 6 years ago by thomas.mckearney@…

Breaking on unhandled exceptions still breaks on the exception.

If it's unhandled, yes. Nothing in my app is unhandled. We don't let our apps crash. There's always a "gentle" failure.

When we expect a browser to throw an error and it doesn't, that is a browser bug. Do you have another way to detect something like that?

The only thing I can think of is to use browser detection, since you know which browsers are a problem. I don't like that very much either, but at least the debugging experience would be more useful.

Anyway, I get it. I understand why you're doing it and there's no easy/good way around it. It does kinda suck that you have to do that, but such is life.

I'm going to request the Visual Studio feature I mentioned to make my life easier :)

Thanks for the rapid responses, all!

comment:8 Changed 6 years ago by anonymous

Of course, you could try not to do it when the file is loaded.. that would be much nicer :)

comment:9 Changed 6 years ago by Jahertor

Just add on the jquery.js file a "try .. catch" statement on the lines you're getting the error. For example, I got an error on line 3686:

matches.call( div, "[s!='']:x" );

So I fixed with:

assert(function (div) {
	try {
	     // Check to see if it's possible to do matchesSelector
	     // on a disconnected node (IE 9)
	     support.disconnectedMatch = matches.call( div, "div" );

	     // This should fail with an exception
	     // Gecko does not error, returns false instead
	     matches.call( div, "[s!='']:x" );
	     rbuggyMatches.push( "!=", pseudos );
	} catch (Exception) { }
});

I don't know if this works for your problems, but it works for me!

Greetings.

comment:10 in reply to:  9 Changed 6 years ago by Jahertor

Replying to Jahertor:

I don't know if this works for your problems, but it works for me!

Greetings.

I rectify, it seems fixed but not, sometimes still throws Exceptions...

comment:11 Changed 6 years ago by anonymous

@Jahertor Sizzle already uses a try/catch internally in the assert function. Your code isn't actually doing anything different from what Sizzle already does. Worse, now you can't use versions from a CDN.

comment:12 Changed 6 years ago by anonymous

jQuery is wrong here. Not Visual Studio.

If you check Safari 7, it will stop every damn time on div.querySelectorAll("*,:x"); when using “stop on unhandled exceptions”. So, this is cross-browser issue.

comment:13 Changed 6 years ago by anonymous

I just want to say thanks to all of you for documenting this so specifically. It really helps the rest of us quite a bit to come here and find out that we aren't the only ones. Yes it would sure help if we could rectify this in VS in some way.

comment:14 Changed 6 years ago by synth3tk

Well either jQuery or VS should do something to rectify this. It's a very frustrating bug/feature to come across while debugging. It also fails the Windows Store certification process.

comment:15 Changed 5 years ago by anonymous

I also have the same issue, my app had been working great up until yesterday when I encounted this bug. I have no idea why this suddenly happened.

comment:16 Changed 5 years ago by dmethvin

#14749 is a duplicate of this ticket.

Note: See TracTickets for help on using tickets.