Community
Participate
Working Groups
Build Identifier: I20110428-0848 The JavaScript Editor complains about minified JS files. This happens mostly because of optional semicolon problem, Syntax error on token "Invalid Regular Expression Options" and some other problems (depending on JavaScript Validator preferences) See the attached examples and screenshot. Other problems: the editor and the eclipse hang while editing long lines, JVM crashes while activating/deactivating JavaScript Editor and while trying to call a context menu on JS-files in Package Explorer (see attached logs) Reproducible: Always Steps to Reproduce: 1. Copy the attached scripts to workspace and open one of these scripts in JavaScript Editor 2. See the Error markers on the JS-code line as well as Error in Problems View
Created attachment 197775 [details] Problematic minified JS file
Created attachment 197776 [details] Problematic minified JS file
Created attachment 197777 [details] Screenshot
Created attachment 197778 [details] Thread dump (mentions libswt-pi-gtk native)
Created attachment 197779 [details] Another thread dump (doesn't look related)
I too am seeing these errors; more disturbingly, I cannot figure out any way to turn off the validation process that's generating them. I've enabled project-specific client-side Javascript validation in my project and the excluded the minified jQuery file (in my case, jQuery 1.6.3), but the errors and warnings still show up in the Problems view. I've turned off all Javascript validation entirely (turning it off both for Manual and Build), but the problems don't disappear from the view. I've also disabled the various Javascript- and validation-related builders for my project (a Dynamic Web Project), and the problems persist. It's almost as if they're either being generated by something *other* than the validator, or that there's a cache that's persisting. Of note, after I disable the client-side Javascript validators and then right-click on my project and choose Validate, the dialog box says that zero errors were found -- yet the three minified jQuery-related errors *still* show in the Problems view.
I dont think it only occurs on Linux, I have the same problem on Win7(In reply to comment
Same problem here (Indigo). And the errors cannot not deactivated by changing the validation settings. (File is jquery-1.6.4.min.js)
Does anyone know if there's logging or other output that we can provide to help narrow down where this is happening? It's getting pretty frustrating to be unable to clear the red-X warnings on projects that include affected "invalid" files.
Seeing this as well in Indigo SR1 on jquery-1.6.2.min.js. As previously mentioned by others turning off validation and doing a Project Clean... does not seem to get rid of them.
The Client-side JavaScript Validator only validates JavaScript in web pages, as its name implies. For standalone files the JavaScript Validator *Builder* is the one to turn off, but doing so means having to remove the entries from the Problems view manually.
Thank you, Nitin -- that definitely helps narrow this down. Disabling the "Javascript Validator" entry in the Builders configuration for my project, manually deleting the jquery-1.6.3.min.js-related errors in the Problems view, and then rebuilding the project seems to do the trick -- the errors don't come back. But now I'm in the position where the Javascript Validator is turned off, all because of a problem with its validation of a single file. So I guess I have two questions: 1. Is there any way to configure ignore lists for the Javascript Validator builder for a given project? 2. Does the Client-side Javascript Validator hav any dependencies on the Javascript Validator builder? In other words, if the latter is disabled, does the former still work?
(In reply to comment #12) > 1. Is there any way to configure ignore lists for the Javascript Validator > builder for a given project? No. > 2. Does the Client-side Javascript Validator hav any dependencies on the > Javascript Validator builder? In other words, if the latter is disabled, does > the former still work? Yes, there is no direct relationship between the two as far as usage is concerned.
(In reply to comment #13) > (In reply to comment #12) > > 1. Is there any way to configure ignore lists for the Javascript Validator > > builder for a given project? > > No. Is there an open feature request for this? It seems like that's what's needed to solve this issue... I'm happy to create one, but figured I'd check first.
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > 1. Is there any way to configure ignore lists for the Javascript Validator > > > builder for a given project? > > > > No. > > Is there an open feature request for this? It seems like that's what's needed > to solve this issue... I'm happy to create one, but figured I'd check first. I have found that I can leave the JavaScript Validator enable and ignore specific files by adding a suitable exclusion pattern e.g. **/jquery*.js to the JavaScript/Include Path/Source/Excluded group (Project->Properties->JavaScript->Include Path->Source). I found that I also needed to manually delete the old problem markers.
I think the authors of JSDT donot know Javascript Language. I suggest let us close the javascript validation. But eclipse jee 3.7.1 canot close JS validation.I close the Preference of javascript validation and make the level be Ignore ,but eclipse Problems still reports the problems (errors and warnings) of Javascript type . Guys , you all can import a js file ,like JQuery-1.x.min.js , so that you can find too many errors.
Also in Windows 7
(In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #13) > > > (In reply to comment #12) > > > > 1. Is there any way to configure ignore lists for the Javascript Validator > > > > builder for a given project? > > > > > > No. > > > > Is there an open feature request for this? It seems like that's what's needed > > to solve this issue... I'm happy to create one, but figured I'd check first. > > I have found that I can leave the JavaScript Validator enable and ignore > specific files by adding a suitable exclusion pattern e.g. **/jquery*.js to the > JavaScript/Include Path/Source/Excluded group > (Project->Properties->JavaScript->Include Path->Source). > > I found that I also needed to manually delete the old problem markers. One way is that : 1.remove javascript -> validator -> errors/warning. 2.remove project -> .project file -> javascript command 3.It is important,too! delete js file and import again.
I have been using the workaround suggested by Nic in Comment #15 for some time, but as of Indigo SR2 the user interface described does not appear to be available anywhere. Is there somewhere else this setting can be configured?
Please ignore last comment. Project properties, not general preferences.
Any chance this can be investigated for 3.9?
Just confirming this problem still exists in Juno Release.
Issue still occurred. Environment: - Eclipse Indigo SR2 (Build ID 20120216-1857). - Windows 7 Professional Service Pack 1.
Created attachment 220670 [details] Modified grammar file Current grammar file (js.g) does not follow javascript standard. According to ECMA-262 5th, only first expression in Expression Statement should not start with 'function' or '{'. However, current js.g prevents all expression in Expression Statement starting with 'function' or '{'. In current js.g 767 ListExpressionStmt -> AssignmentExpressionStmt 768 ListExpressionStmt ::= ListExpressionStmt ',' AssignmentExpressionStmt should be 767 ListExpressionStmt -> AssignmentExpressionStmt 768 ListExpressionStmt ::= ListExpressionStmt ',' AssignmentExpression (also 1056, 1061, 1090, 1094, 1197 should be fixed) AssignmentExpression derives all expression whereas AssignmentExpressionStmt does not derive 'function' and '{'. So, below valid sentences are invalid in current grammar. x, function y() {}; // this pattern is frequently used in minified js library. x, {}; You can fix your parser with attached grammar file. (http://www.eclipse.org/jdt/core/howto/generate%20parser/generateParser.html, use jsdtcore.jar instead) I'm not sure this grammar is safe for other cases. For this issue, it works.
Comment on attachment 220670 [details] Modified grammar file Current grammar file (js.g) does not follow javascript standard. According to ECMA-262, only first expression in Expression Statement should not start with 'function' or '{'. However, current js.g prevents some other expressions from starting with 'function' or '{'. For example, in current js.g: 767 ListExpressionStmt -> AssignmentExpressionStmt 768 ListExpressionStmt ::= ListExpressionStmt ',' AssignmentExpressionStmt should be 767 ListExpressionStmt -> AssignmentExpressionStmt 768 ListExpressionStmt ::= ListExpressionStmt ',' AssignmentExpression (also 1056, 1061, 1090, 1094, 1197 should be fixed) AssignmentExpression derives all expression whereas AssignmentExpressionStmt does not derive 'function' and '{'. So, below valid program are invalid in current grammar. x, function y() {}; // this pattern is frequently used in minified js library. x, {}; You can fix your parser with attached grammar file. (http://www.eclipse.org/jdt/core/howto/generate%20parser/generateParser.html, use jsdtcore.jar instead)
Per this thread [1] vjet team was asked to look at this bug to see if it also applies to vjet. This bug appears to also apply to VJET's fork of JSDT AST parser. I receive multiple errors on jquery minified. Bug 399415 for VJET has been created to track this on VJET project. [1] http://dev.eclipse.org/mhonarc/lists/vjet-dev/msg00022.html
I have looked at this patch and applied it to VJET JS IDE's js parser. After applying this fix jquery min 1.9 doesn't have any syntax errors. There are some issues with VJET type checking which will be handled in a different bug. see bug 399415 for more info.
Any chance this making it into 4.3?
There is currently no plan to get VJET into 4.3. VJET JS IDE (in incubation) is currently distributed in the Eclipse marketplace. http://marketplace.eclipse.org/content/vjet-javascript-ide
I am not a user of VJET. Sorry for the confusion. I mean can someone think about slating this for the vanilla 4.3 installation of Eclipse?
4.3 would be the Eclipse version; for WTP that would be our 3.5 release. We'll try.
*** Bug 417387 has been marked as a duplicate of this bug. ***
I verified parser generated out of attached js.g file and it works. All tests form org.eclipse.wst.jsdt.core.tests.compiler in JSDTCompilerTests pass with new parser. No errors for minified JQuery js files. 25 votes should be enough to apply it in 3.5.2 and 3.6, shouldn't it? Going to add tests for parser to test fixed JavaScript problems.
Is there a patch ready to apply? I only see the grammar file attached to this bug.
Created attachment 237381 [details] webtools.jsdt.core master branch patch
Created attachment 237382 [details] webtools.jsdt.tests master branch patch with test for the fix added
(In reply to Chris Jaun from comment #34) > Is there a patch ready to apply? I only see the grammar file attached to > this bug. Patches are attached. I tested various compressed and uncompressed jQuery js files and haven't seen any errors reported.
(In reply to Denis Golovin from comment #37) > (In reply to Chris Jaun from comment #34) > > Is there a patch ready to apply? I only see the grammar file attached to > > this bug. > > Patches are attached. I tested various compressed and uncompressed jQuery js > files and haven't seen any errors reported. The core patch misses all the binary changes to the *.rsc files and is also missing the changes to readableNames.properties - once you re-gen the parser it all works fine and all tests pass. Smoke testing using a variety of minified files and the entire Orion code-base does not produce any unexpected errors.
(In reply to Michael Rennie from comment #38) > (In reply to Denis Golovin from comment #37) > > (In reply to Chris Jaun from comment #34) > > > Is there a patch ready to apply? I only see the grammar file attached to > > > this bug. > > > > Patches are attached. I tested various compressed and uncompressed jQuery js > > files and haven't seen any errors reported. > > The core patch misses all the binary changes to the *.rsc files and is also > missing the changes to readableNames.properties - once you re-gen the parser > it all works fine and all tests pass. Smoke testing using a variety of > minified files and the entire Orion code-base does not produce any > unexpected errors. I didn't include files that weren't changed: 1. parser[21,24].rsc are the same after generation (at least git doesn't show them as changed) 2. Generated readableNames.properties have no copyright comment, but everything else is the same.
(In reply to Denis Golovin from comment #39) > > I didn't include files that weren't changed: > 1. parser[21,24].rsc are the same after generation (at least git doesn't > show them as changed) > 2. Generated readableNames.properties have no copyright comment, but > everything else is the same. Weird. Did you forget to run the UpdateParserFiles class after the parser updates? Once you do that step and copy the files over, they are all changed.
Yes, I did all by the jdt doc about generating parser, and run (In reply to Michael Rennie from comment #40) > (In reply to Denis Golovin from comment #39) > > > > > I didn't include files that weren't changed: > > 1. parser[21,24].rsc are the same after generation (at least git doesn't > > show them as changed) > > 2. Generated readableNames.properties have no copyright comment, but > > everything else is the same. > > Weird. Did you forget to run the UpdateParserFiles class after the parser > updates? Once you do that step and copy the files over, they are all changed. Yes, I did all by the jdt doc updating parser and ran UpdateParserFiles. I had problems on Linux, but everything worked fine on windows. Then I moved them over to my linux desktop and made the patches. Then tested patch under linux and windows.
(In reply to Michael Rennie from comment #40) > (In reply to Denis Golovin from comment #39) > > > > > I didn't include files that weren't changed: > > 1. parser[21,24].rsc are the same after generation (at least git doesn't > > show them as changed) > > 2. Generated readableNames.properties have no copyright comment, but > > everything else is the same. > > Weird. Did you forget to run the UpdateParserFiles class after the parser > updates? Once you do that step and copy the files over, they are all changed. I've replicated all the steps of re-generating the parser and achieved the pretty same results: All the *.rsc were regenerated. Didn't compare their content, but I see all of them in my git-patch as well as in Dennis' patch (look at the source - you'll see all those *.rsc files there in Denis's patch). Generated readableNames.properties is the same as before, except the header comment. I've restored the comment in my version and modified the year of last change. So, git diff shows the only 1 comment line (with that year) has changed. In my case the parser also works as expected. So, I'm +1 for the Denis' patch to be pushed (If those 'year of change' in comments is not so important).
Please also consider proposed patches for Kepler SR2 release. Explain why you believe this is a stop-ship defect: * Parser fails for many compressed js libraries and thus errors reported for correct projects. Is there a work-around? If so, why do you believe the work-around is insufficient? * Validation can be disabled but that lead to loosing valuable functionality like content assist. How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? * Tested with JSDT JUnit tests for parser and ast model. All tests are passed with no errors. Test added to verify that function expression now accepted in List Expression Statements. Attached patches are tested against master and 3_5_maintenance branches Give a brief technical overview. Who has reviewed this fix? * In previous js.g was: 767 ListExpressionStmt -> AssignmentExpressionStmt 768 ListExpressionStmt ::= ListExpressionStmt ',' AssignmentExpressionStmt in new js.g is: 767 ListExpressionStmt -> AssignmentExpressionStmt 768 ListExpressionStmt ::= ListExpressionStmt ',' AssignmentExpression (also fixed in some other lines where List Expression Statements can be used) AssignmentExpression derives all expression whereas AssignmentExpressionStmt does not derive 'function' and '{'. What is the risk associated with this fix? * Low. All JUnit Tests are good after applying the patches in master and 3_5_maintenance branches. Parser doesn't report errors for latest jQuery compressed js files (tested manually).
Denis, I'm getting ready to push this. Can you add the Certificate of Orgin sign off statement to the comments of this bugzilla? Described near the bottom of this page: http://wiki.eclipse.org/Development_Resources/Contributing_via_Git
(In reply to Chris Jaun from comment #44) > Denis, I'm getting ready to push this. Can you add the Certificate of Orgin > sign off statement to the comments of this bugzilla? Described near the > bottom of this page: > http://wiki.eclipse.org/Development_Resources/Contributing_via_Git This contribution complies with http://www.eclipse.org/legal/CoO.php
Pushed to 3.5.2 and 3.6.
http://git.eclipse.org/c/jsdt/webtools.jsdt.core.git/commit/?id=8f3e19d68892f30d8ff7354965f5bde0bf3a68ba
(In reply to Chris Jaun from comment #46) > Pushed to 3.5.2 and 3.6. Nice - but what about pushing it to Eclipse 4 as well? I'm using version 4.3.2 (Build id: M20140101-1810) and the issue still occurs.
@Alexander: versions listed here are JSDT versions. JSDT 3.5.2 will be part of Kepler SR2 (due February) and JSDT 3.6 will be part of Eclipse 4.4 Luna (June). You may already be able to use the WTP Integration Build from http://download.eclipse.org/webtools/downloads/drops/R3.6.0/I-3.6.0-20131217131919/repository/ to give a try to this change before it gets part of a release.
Verified on Luna M4, no more errors in minified jQuery files. @Victor, could you confirm that and mark the issue as verified?
(In reply to Denis Golovin from comment #50) > Verified on Luna M4, no more errors in minified jQuery files. > @Victor, could you confirm that and mark the issue as verified? Yes, this issue is gone, but some UI issues are still occuring (See Bug #424131 and Bug #424193). Those two UI issues still making the Editor to complain on JSDT errors/warnings. Bug #424131 is fixed in WTP R352 integration build 01022014, while other has a work around (a user might type a char or just close and open the editor again due to see those errors/warnings gone)
Verified for WTP 3.5.2 and WTP 3.6
