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.
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.
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?
Flags: needinfo?(jimb) → needinfo?(nfitzgerald)
(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.
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
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.
Still broken in Firefox 35 on windows 7 SP1 x64, and Firefox 34.0.5 on OpenSUSE 13.1 x64.
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.
You need to log in before you can comment on or make changes to this bug.