Chrome Debugger Moves and Prevents Setting Breakpoints in Generated Javascript

[godonnell_ip]

This is quite possibly not an issue caused by SmartGWT, so please forgive me if it is not. I've searched elsewhere for answers to this issue but have not yet had any luck.

I thought I might be the only one experiencing this, but my colleagues have also noticed it, which made me think it might be our code or development environments that were somehow out of whack. However, while researching another issue with the latest nightly build and using only SDK sample code I noticed the same thing: the Chrome debugger will happily show me my Java code, but often refuses to set a breakpoint at the place I would like it to be - many times it will move it up or down a line or two, to the method's declaration, or will just not allow the breakpoint anywhere on or within a method.

I understand how my Java code is optimized during compilation and therefore code contained within conditions may be optimized to a single Javascript line. I am quite used to that and have no problem working around it. However, this is a fairly newly observed behavior (within the last couple of months) and is much more agitating.

For example, while debugging a slightly modified BuiltInDS project, I have the following lines in BuiltInDS.java

161        IButton filterBtn = new IButton("Filter");
162        filterBtn.addClickHandler(new ClickHandler() {
163            public void onClick(ClickEvent event) {
164                boundList.filterData(fb.getCriteria());
165                saveBtn.disable();
166            }
165        });
168        hLayout.addMember(filterBtn);
169
170        vStack.addMember(hLayout);

• If I place a breakpoint on line 164, the debugger accepts is briefly, but moves it to line 165.
• If I place one on line 165, the debugger moves it to line 163.
• If I place one on line 163, the debugger moves it to line 164.
• If I place one on line 168, the debugger moves it to line 170.

In this example, I can actually place a breakpoint on lines 164 and 165, albeit in a roundabout way, but I often find it's not possible to get one on the specific line I need. In earlier iterations of my testing I was unable to get a breakpoint on line 164 until I added some useless lines of code above it and set breakpoints on them:

161        IButton filterBtn = new IButton("Filter");
162        filterBtn.addClickHandler(new ClickHandler() {
163            public void onClick(ClickEvent event) {
164                int x = 1;
165                int y = 2;
166                y= y+x;
167                boundList.filterData(fb.getCriteria());
168                saveBtn.disable();
169            }
170        });
171        hLayout.addMember(filterBtn);
172
173        vStack.addMember(hLayout);

Has anyone else experienced this, or does anyone have any ideas what I might have misconfigured or otherwise incorrect in my environment? It is getting to the point that the debugger is less and less useful to me as it takes more time to work around the debugger's quirks than to use more brute-force methods to debug.

[Isomorphic]

This is a limitation of GWT's source maps. You didn't mention what version of SGWT or GWT that you're using, but looking at SGWT 5.1p and GWT 2.6.1, we do similar behavior to what you describe in Chrome. Switching to GWT 2.7 improves the situation - we don't see any breakpoints rejected or moved. However, we do see that a few breakpoints appear to be hit out of order - this may be an unavoidable consequence of the GWT compilation process.

Firefox was much more difficult to use, not hitting all of the breakpoints and not providing a proper stack trace when it did.

[godonnell_ip]

Thank you for validating that what we are seeing is expected (if undesirable). I feel fairly sure that the occurrences of this have increased within the last few months, but that may just be my perception rather than reality. We are currently using SGWT 5.0 and GWT 2.6.0. I've toyed with GWT 2.7.0 and will probably give it another whirl if you believe things are better with it.

Thanks again for the response.