Description Nitin Dahyabhai 2009-05-19 16:31:43 EDT

Created attachment 136384 [details]
proposed patch

+++ This bug was initially created as a clone of Bug #243886 +++

* Explain why you believe this is a stop-ship defect.
As in the original bug report, there are some cases that our JS validation can't or won't handle correctly, even when that code works within the browser's runtime.  Although much of this was added through a headless preference introduced in 3.0.2, there was no UI added to let the user control it.

* Is there a work-around?
No, some validation checks are not surfaced through the preferences at all because they're deemed essential to having properly running code, but some toolkits that declare classes using alternate means are simply reported as broken.

* How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added?
Manually tested as this is largely a backport from 3.1, but the remaining JSDT unit tests are used to ensure that reporting of semantic problems defaults to being as it was in 3.0.4.

* Give a brief technical overview. Who has reviewed this fix?
This patch modifies the JSDT "Compiler" so that it's possible to bypass any generated problem messages other than those representing detected tasks or syntax problems.

* What is the risk associated with this fix? 
Low, apart from the introduction of an externalized UI string.  Users upgrading existing workspaces from 3.0.x to 3.0.5 should not notice any difference.