Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 338460

Summary:	NPE when script with JSDT breakpoint encountered
Product:	[WebTools] JSDT	Reporter:	Grant Gayed <grant_gayed>
Component:	Debug	Assignee:	Michael Rennie <Michael_Rennie>
Status:	ASSIGNED ---	QA Contact:	Michael Rennie <Michael_Rennie>
Severity:	normal
Priority:	P3	CC:	david_williams, thatnitind
Version:	unspecified
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Grant Gayed

2011-02-28 15:10:36 EST

I think this is a side effect of last Friday's changes.  The steps below give a specific case, but presumably the problem happens with other sites as well.

- delete the External Javascript Source project just to ensure that you're starting with a clean state
- connect to a Crossfire server
- navigate to ottawa.ca
- open the source for its http://translate.google.com...element.js script (it has three lines)
- put a breakpoint on its top line (note: it does not matter if this breakpoint is sent to the Crossfire server or not, JSDT just need to know about it)
- navigate to any other site
- navigate back to ottawa.ca and the following NPE happens:

java.lang.NullPointerException
	at org.eclipse.wst.jsdt.debug.internal.core.breakpoints.JavaScriptBreakpoint.scriptPathMatches(JavaScriptBreakpoint.java:456)
	at org.eclipse.wst.jsdt.debug.internal.core.breakpoints.JavaScriptBreakpoint.handleEvent(JavaScriptBreakpoint.java:434)
	at org.eclipse.wst.jsdt.debug.internal.core.model.EventDispatcher.dispatch(EventDispatcher.java:125)
	at org.eclipse.wst.jsdt.debug.internal.core.model.EventDispatcher.run(EventDispatcher.java:95)
	at java.lang.Thread.run(Unknown Source)

Comment 1 Michael Rennie

2011-03-01 11:29:35 EST

(In reply to comment #0)
> I think this is a side effect of last Friday's changes.  The steps below give a
> specific case, but presumably the problem happens with other sites as well.
> 

Yes, this one is kind of a double-whammy. Changes released on Friday simplified some of the script comparisons, but did not handle the script load case for about:blank that crossfire sends. Arguably this should be handled in the crossfire implementation of ScriptReference:sourceURI() - the form of the URI we get now has no path and a scheme of 'about' and decoded scheme segment of 'blank', which is bogus.

Comment 2 Michael Rennie

2011-03-01 13:26:45 EST

I am wondering if we should ever care about about:blank loads? Should we just ignore them altogether? Is there ever a case when someone would want to the know that this loaded?

Comment 3 Michael Rennie

2011-03-01 13:33:03 EST

another thing to consider, why is the Crossfire server holding about:blank as a script?

For example when we send a 'scripts' request, one of the entries we get back is:

{script={id=about:blank, lineOffset=0, sourceLength=1, lineCount=1, compilationType=URLOnly, sourceStart=The resource from this URL is not text: about:blank, columnOffset=0}}

Comment 4 Grant Gayed

2011-03-25 16:06:05 EDT

This works for me in the latest, tried with both IE and FF.  Closing report.

Comment 5 Michael Rennie

2011-03-25 17:31:13 EDT

This does work in the latest code, but only because I hacked it. We should fix it 'properly' by:

1. preventing script objects from being created for about:blank AND / OR
2. fixing crossfire itself to not send script load events for about:blank

Comment 6 Nitin Dahyabhai

2011-04-25 11:30:05 EDT

Michael, will we be doing a "proper" fix for 3.3.0 (which will require PMC approval going forward), or do you want to defer this to 3.3.1?

Comment 7 David Williams

2011-05-12 12:01:58 EDT

Since no answer to question in comment #6, I am assuming and moving to 3.3.1. 

Feel free to triage/handle in a different way ... such as could have closed one, and clone a new one for future? ... I just didn't want to leave it targeted to a past milestone since more likely to be overlooked?