Skip to main content

Bug Tracker

Side navigation

#13274 closed bug (fixed)

Opened January 20, 2013 10:47AM UTC

Closed January 25, 2013 03:08PM UTC

Last modified May 08, 2013 08:35PM UTC

IE < 9: "'jquery' is undefined" w/ sourceMappingURL comment

Reported by: alexc223@gmail.com Owned by: alexc223@gmail.com
Priority: blocker Milestone: 1.9.1
Component: build Version: 1.9.0
Keywords: Cc: paul.irish
Blocked by: Blocking:
Description

When using MSIE < 9 and jQuery 1.9.0 I am getting the following warning/error:

'jquery' is undefined

This error is coming from line 4 in the minified versions, which is (a comment!):

//@ sourceMappingURL=jquery.min.map
Attachments (0)
Change History (25)

Changed January 20, 2013 10:12PM UTC by dmethvin comment:1

owner: → alexc223@gmail.com
status: newpending

Can you provide a test page that we can use? I include *just* the minified 1.9.0 and it seems to work fine.

Changed January 21, 2013 07:08PM UTC by chris@achievementstats.com comment:2

I can confirm this bug. You can see it live on http://www.achievementstats.com/

Changed January 22, 2013 05:58PM UTC by dmethvin comment:3

component: unfiledbuild
milestone: None1.9.1
priority: undecidedblocker
status: pendingopen

It definitely is happening on those sites, although I can't reproduce it with this simple jsfiddle: http://jsfiddle.net/dmethvin/vvtJN/3/

If you get into the IE8 debugging console and type //@ sourceMappingURL=jquery.min.map you see the same error as above though, so it does seem real. We just need to figure out what conditions cause it.

Changed January 22, 2013 10:47PM UTC by dmethvin comment:4

I am starting to feel sick...it's conditional code.

http://www.javascriptkit.com/javatutors/conditionalcompile.shtml

If someone, anyone, uses //@cc_on before jQuery loads it looks like the sourceMappingURL line will cause an error in IE8.

http://imgur.com/x2RL8KJ

Supposedly it can be turned off with @cc_off but that would have to be in OUR source file for defensive purposes and would affect following code.

Changed January 23, 2013 12:11AM UTC by anonymous comment:5

This will affect *all versions* of IE, not just IE8. See this fiddle in IE10 or below.

Changed January 23, 2013 12:50AM UTC by paul.irish comment:6

Okay spent some time on this with Jake Archibald...

This is where WebKit parses the comment. It does NOT need to start on a newline, but there are some other specifics in the regex it's looking for: https://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/inspector/ContentSearchUtils.cpp&exact_package=chromium&q=sourceMappingURL&type=cs&l=143

Two possible fixes...

jQuery-side fix..

Augment the current reference with flowerbox comments (on new lines).

/*
//@ sourceMappingURL=undeclaredIdentifier
*/

cc_on's will still work (and so will the sourcemapping), but IE won't try to parse this as a CC directive.

User-side fix

Since this is only repro'd when a page turns on conditional compilation before including jQuery, DONT DO THAT.

1. Don't use @cc_on

1. Include jQuery before one of your scripts turns on @cc_on

1. stop using some super old legacy version of the html5shiv and update to the latest version

1. Don't use @cc_on. Use this instead https://gist.github.com/527683

1. @cc_on dramatically slows down js evaluation. don't use it.

Changed January 23, 2013 07:15PM UTC by alexc223@gmail.com comment:7

Yep, I can confirm that's the case - an old html5shiv was in use, which uses conditional compilation. Upgrading to the latest html5shiv (which no longer uses it), has resolved this for me.

Changed January 24, 2013 12:15AM UTC by chris@achievementstats.com comment:8

AchStats.com uses this table sort script:

http://www.frequency-decoder.com/2006/09/16/unobtrusive-table-sort-script-revisited

It has indeed conditional code, but that's nothing we could change. However loading jQuery before loading the sort script has resolved the issue! Thanks for the research. :)

Changed January 24, 2013 12:38AM UTC by gibson042 comment:9

As it turns out, we can fix this and even save a byte: https://github.com/jquery/jquery/pull/1143

Whether we ''want'' to remains an open question.

Changed January 25, 2013 03:08PM UTC by Richard Gibson comment:10

resolution: → fixed
status: openclosed

Fix #13274: Wrap sourceMap directive in multiline comments. Close gh-1143.

Changeset: ac93559eb9f18fcaec95dfdc97358b1b85bfe234

Changed January 25, 2013 03:11PM UTC by Richard Gibson comment:11

Fix #13274: Wrap sourceMap directive in multiline comments. Close gh-1143.

(cherry picked from commit ac93559eb9f18fcaec95dfdc97358b1b85bfe234)

Changeset: 487b703521e63188102c73e8ce6ce203d28f260b

Changed February 04, 2013 02:08AM UTC by Matt Robenolt <matt@ydekproductions.com> comment:12

I just noticed now in master that the //@ sourceMappingURL= indicator is now at the top of the document.

According to the version 3 spec for source maps, it explicitly says it should be at the end of the document. I'm not sure how these are implemented at the browser level, but could it cause any issues? Or should this idea be brought up to browser devs and have the spec loosened?

Spec document:

https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit#heading=h.txk3vdsh99hf

Compiled source from master: https://gist.github.com/raw/43037ab16b9b22d1ceb0/gistfile1.js

Changed February 04, 2013 03:45AM UTC by gibson042 comment:13

I observe that particular statement to be in the "Conventions" section, and also that a strict reading would prohibit the trailing */ required by this ticket. Given that our current approach was specifically crafted to match browser implementation, who do we talk to about updating the spec?

Changed February 04, 2013 04:02AM UTC by dmethvin comment:14

cc: → paul.irish

Probably good to pull in Paul Irish here. I am not at all a fan of the current "convention" of using a newline-terminated comment at the end of the file. It also makes more sense for the comment to be a the top of the file. But we should get all the parties involved to agree on what is within the spec.

While we're changing the spec it would be great to pick a sequence that wasn't already in use by @cc_on.

Changed February 05, 2013 05:21PM UTC by Matt Robenolt <matt@ydekproductions.com> comment:15

According to the source of both WebKit and FF, this will technically work. Both work by just looking for a comment that fits that pattern, which technically could be left open to the sourceMappingURL indicator being *anywhere* in the document.

(Slightly out of the scope of this discussion), but I think the beginning of the document makes a lot of sense for implementations other than a browser for one good reason:

It's possible to stream in bytes and detect a source map without loading the whole file into memory. If the source map could be detected early, you can disregard the rest and just fetch the source.

Granted, it's a small idea, but it makes sense to me. Or just strictly use the proposed SourceMap header, which seems the cleanest of them all.

Changed February 06, 2013 03:35PM UTC by dmethvin comment:16

Using the HTTP header may seem like a good idea but isn't. Most web devs can change the content of a file with no problem but can't change the headers sent with the file without access to server configuration. It also won't work if the file is used locally.

Changed February 07, 2013 07:31PM UTC by mattrobenolt comment:17

@dmethvin Good point. It is harder to maintain a header. So maybe just a preference for a header if possible. :)

Changed February 08, 2013 04:31PM UTC by adam.dorsey@picdorsey.com comment:18

I still get an error in IE8, even when using the fix:

/*

//@ sourceMappingURL=undeclaredIdentifier

*/

Changed February 08, 2013 04:32PM UTC by adam.dorsey@picdorsey.com comment:19

Sorry, here it is in a proper code block:

/*
//@ sourceMappingURL=undeclaredIdentifier
*/

Changed April 02, 2013 01:07PM UTC by meelash comment:20

Paul, do you have any numbers/tests/explanation for why turning on cc slows down js? Is this in IE only (given that other browser should be ignoring it as a comment)?

Replying to [comment:6 paul.irish]:

Okay spent some time on this with Jake Archibald... This is where WebKit parses the comment. It does NOT need to start on a newline, but there are some other specifics in the regex it's looking for: https://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/inspector/ContentSearchUtils.cpp&exact_package=chromium&q=sourceMappingURL&type=cs&l=143 Two possible fixes... == jQuery-side fix.. == Augment the current reference with flowerbox comments (on new lines).
> /*
> //@ sourceMappingURL=undeclaredIdentifier
> */
> 
cc_on's will still work (and so will the sourcemapping), but IE won't try to parse this as a CC directive. == User-side fix == Since this is only repro'd when a page turns on conditional compilation before including jQuery, DONT DO THAT. 1. Don't use @cc_on 1. Include jQuery before one of your scripts turns on @cc_on 1. stop using some super old legacy version of the html5shiv and update to the latest version 1. Don't use @cc_on. Use this instead https://gist.github.com/527683 1. @cc_on dramatically slows down js evaluation. don't use it.

Changed May 08, 2013 08:02PM UTC by anonymous comment:21

Will this be fixed in a future version? I have web essentials installed which will automatically change my minified files back to the single line comment. The workaround of a multiline flower comment does not work with Web Essentials.

Changed May 08, 2013 08:11PM UTC by dmethvin comment:22

On our end, the only option we have is to remove support for sourcemaps altogether.

Your tools should not be mangling that comment, I can't think of a reason why they would do that. If you are combining/(re)compressing files the comment becomes useless anyway because the map no longer represents the new file. Remove it or remove it not, there is no mangle.

Changed May 08, 2013 08:20PM UTC by anonymous comment:23

Replying to [comment:22 dmethvin]:

On our end, the only option we have is to remove support for sourcemaps altogether. Your tools should not be mangling that comment, I can't think of a reason why they would do that. If you are combining/(re)compressing files the comment becomes useless anyway because the map no longer represents the new file. Remove it or remove it not, there is no mangle.

What I'm saying is that Web Essentials automatically creates the minfied file and map file when you save the unminified file. So if I save the unminified file, the minified file gets re-created with the single line comment.

Changed May 08, 2013 08:24PM UTC by dmethvin comment:24

Well that's not jQuery's issue at all, Web Essentials is creating an incompatible file. You'll need to let the Web Essentials people know they're generating a file that causes errors in IE and/or convince the sourcemap folks to adopt a syntax that is compatible with IE's @cc_on. I haven't had much luck with the latter myself.

Changed May 08, 2013 08:35PM UTC by m_gol comment:25

@dmethvin I've talked to Nick Fitzgerald at the Front Trends conference in Warsaw recently and he's open to changing the @ symbol, in his presentation about source maps he even directly said that it'll probably change. I'm optimistic about that.