Community
Participate
Working Groups
Currently after invoking content assist in an HTML document in a STYLE element and selecting a JavaScript method with fields the fields are automatically added but there is no tabbing between fields so then the user is forced to manually delete each of the automatically inserted fields so as to insert the correct ones. Also there is no automatic consumption of the closing parentheses.
Created attachment 169862 [details] Fix Patch the problem here is that in JSDTCompletionProsal#apply(ITextViewer, char, int, int) if the wrapped ICompletionProposal is a LazyJavaCompletionProposal then ICompletionProposalExtension#apply(IDocument, char, int) is being called rather then ICompletionProposalExtension2#apply(ITextViewer, char, int, int) and without the viewer then the tabbing fields can not be set up. The same goes for the closing parenthesis consumption. Another addition that has to be made is overriding the #getSelection function so as to use the wrapped proposals #getSelection method rather then supers if its apply method was used (thus if its a LazyJavaCompletionProposal). Seeing as this is all UI improvements I don't have any idea what sort of JUnit would be useful in this situation but adding this scenario to the smoketest would probably be a good idea.
Let's get this in 3.2.
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. The applied JS proposal supplies default values for any arguments and assumes that the UI allows for the user to tab through them quickly for corrections or removal. It fails the expectations of users of the standalone JavaScript editor when working in web pages, but in a way which we can actually address relatively easily. * Is there a work-around? If so, why do you believe the work-around is insufficient? Disable the (enabled by default) "Fill argument names on completion" option in the JavaScript Editor Content Assist preferences, but this would apply to the JS editor as well. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Manual testing. * Give a brief technical overview. Who has reviewed this fix? Updates the proposal class to apply the proposal class using a method that passes in the viewer. * What is the risk associated with this fix? Low. Only affects JS proposals in web pages.
I agree this would be "missing function" (albeit small) and it is in an area (JSDT) that we want to highlight this release. Seems safe enough.
Appears to be low risk.
Released into v201006030742.
