Skip to main content

Bug Tracker

Side navigation

#14123 closed bug (notabug)

Opened July 11, 2013 12:11PM UTC

Closed July 11, 2013 12:13PM UTC

Last modified February 03, 2014 05:33PM UTC

JavaScript errors just by including jQuery 2.0.2 in WinJS app

Reported by: thomas.mckearney@appliedis.com 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

Attachments (0)
Change History (16)

Changed July 11, 2013 12:12PM UTC by anonymous comment:1

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

Changed July 11, 2013 12:13PM UTC by dmethvin comment:2

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.

Changed July 11, 2013 12:17PM UTC by anonymous comment:3

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.

Changed July 11, 2013 12:28PM UTC by dmethvin comment:4

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.

Changed July 11, 2013 12:32PM UTC by anonymous comment:5

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.

Changed July 11, 2013 01:14PM UTC by timmywil comment:6

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?

Changed July 11, 2013 01:26PM UTC by thomas.mckearney@appliedis.com comment:7

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!

Changed July 11, 2013 01:28PM UTC by anonymous comment:8

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

Changed July 16, 2013 08:54AM UTC by Jahertor comment:9

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.

Changed July 16, 2013 09:36AM UTC by Jahertor comment:10

Replying to [comment:9 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...

Changed July 17, 2013 04:09AM UTC by anonymous comment:11

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

Changed July 19, 2013 09:36AM UTC by anonymous comment:12

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.

Changed August 27, 2013 02:00AM UTC by anonymous comment:13

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.

Changed September 01, 2013 01:00PM UTC by synth3tk comment:14

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.

Changed October 23, 2013 12:46PM UTC by anonymous comment:15

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.

Changed February 03, 2014 05:33PM UTC by dmethvin comment:16

#14749 is a duplicate of this ticket.