Internet Explorer provides conditional compilation in JavaScript.

The syntax for conditional compilation is as follows:

[comment start marker]@keyword ... @[comment end marker]

This allows conditional compilation to be embedded into JavaScript files using single- or multi-line JavaScript comments.

When Internet Explorer parses the file, and reaches a string such as //@, it evaluates it as the start of a conditional compilation statement. If illegal characters are then encountered within the conditional compilation block, Internet Explorer will throw a fatal error and abort processing (meaning any further JavaScript code in the same file will not be executed).

In extlink_extra.js on line 20 there is the following code:

//@todo:

The error message that gets thrown for this code is:

SCRIPT1004: Expected ';'
js_O_pBBiQ2D6MyhAHBLgXPMSS-wgzNZYVhez-REpE26P4.js, line 6 character 12

Directly preceding JavaScript comments with an @ symbol should therefore be avoided.

Comments

psynaptic’s picture

Looking further into this I have found a @cc_on statement in CKEditor module which triggers the conditional compilation mode in Internet Explorer.

After grepping the projects on drupalcontrib.org I have generated the following list of modules that contain the @cc_on statement:

ckeditor
fckeditor
shadowbox
markdowneditor

There are likely others in contrib, these are just the ones found in the branches I have checked out for the projects on drupalcontrib.org.

So the //@ is harmless on its own.

psynaptic’s picture

Status: Needs work » Needs review
StatusFileSize
new1.35 KB

Patch attached which just adds a space before the @todo directive. I was going to clean up the whole file but I thought it best to just keep this patch focused and do the cleanup in a separate issue - unless you'd prefer that I clean it up in this one?

justindodge’s picture

@psynaptic: What an interesting issue you've discovered! I had no idea about conditional compilation in IE.

I was going to clean up the whole file but I thought it best to just keep this patch focused and do the cleanup in a separate issue - unless you'd prefer that I clean it up in this one?

I'm happy to commit your work either way, but seeing as how you've already rolled one patch for this issue, maybe it'd make more sense to start a separate one for the cleanup? I really have no preference though, and I'm glad to have the contributions regardless of how the code is split up.

Thanks!

psynaptic’s picture

Perfect. I'll create another issue to track the cleanup of that file then.

justindodge’s picture

Status: Needs review » Fixed

Committed to 7.x-1.x, thanks again!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

The line number has changed in a more recent version.