949118 - breakpoints don't always work on www.gwtproject.org

Status: UNCONFIRMED

(DevTools :: Debugger, defect)

Description

[Brian Slesinsky]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.41 Safari/537.36

Steps to reproduce:

1. Visit www.gwtproject.org
2. Open the debugger
3. Search for GwtProjectEntryPoint.java
4. Set breakpoints at lines 51, 53, 55, and 57 (in onModuleLoad)
5. Reload the page.


Actual results:

Stops at lines 51 and 53. Doesn't stop at 55 or 57. It does stop at line 50, apparently while leaving the function.



Expected results:

It should stop at each line. This mostly works in Chrome, except that you have to click on the call stack to show the right file after the first breakpoint.

Comment 1

[Brian Slesinsky]

Reproduced on Linux as well. Also, if you stop at line 51 and press "step over" to step through the function, it will stop at line 53 but not at 55 or 57.

Comment 2

[Jim Blandy :jimb]

This is GWT-compiled code, so the stepping irregularities might be due to the source maps, or they might be due to inlining performed by GWT.

Nick, I'm having trouble extracting the URLs for the script and the source maps from our UI. What's the easiest way for me to get these?

Comment 3

[Brian Slesinsky]

I compiled the code with optimizations turned off, so it's not inlining. The JavaScript looks like this (with newlines added):

function $onModuleLoad(this$static) {
  $enhanceMenu(this$static);
  $openMenu();
  $maybeBindPopState(this$static);
  this$static.currentPage = getPath()
}

The JavaScript is installed from within an eval(), so the easiest way to get the URL's is probably to use Chrome (sorry) and look under (no domain) for gwtproject-0.js. Or maybe try the network panel. Anyway, the sourcemap is here:

http://www.gwtproject.org/src/97390A731B3B02D01800264D4A694947_sourceMap0.json

Comment 4

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(In reply to Jim Blandy :jimb from comment #2)
> This is GWT-compiled code, so the stepping irregularities might be due to
> the source maps, or they might be due to inlining performed by GWT.
> 
> Nick, I'm having trouble extracting the URLs for the script and the source
> maps from our UI. What's the easiest way for me to get these?

We don't really have a nice way for that (bug 956088). You just have to toggle source mapping off and look at the //# sourceMappingURL.

GWT is using eval though, so its not really a surprise that the behavior is weird since we don't really debug evaled scripts well.

Possible the source map is bad, would look at it in http://sokra.github.io/source-map-visualization/

Also possible SpiderMonkey's source notes are funky and this is propagating through the system. Even a single column can push us to a different mapping in the source map which could point at *any* line/col/source; little things can have big effects.

Comment 5

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

And apparently I haven't just been imagining that column numbers are unreliable in SpiderMonkey: https://bugzilla.mozilla.org/show_bug.cgi?id=762556#c11

Comment 6

[William Gallafent]

This appears still to be the case in Firefox 30 (My user agent: “Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Firefox/30.0”), using my own small sample project and GWT's Super Dev Mode. The source maps look good, Java source code is appearing in FF's debugger, but breakpoints are not hit.

The same test in Chrome (version 35) does hit breakpoints.

Comment 7

[javascriptjedi]

Still broken in Firefox 35 on windows 7 SP1 x64, and Firefox 34.0.5 on OpenSUSE 13.1 x64.

Comment 8

[javascriptjedi]

The above applies to GWT 2.5.1.  It's apparently working with GWT 2.7.0.

So I suppose it's a lost cause to hope FF with ever be able to actually stop at breakpoints in GWT 2.5.1?  Chrome works.