Super Dev Mode pauses on “invisible” breakpoints & then shows blank screen

Hi everyone,
I’m running GWT Super Dev Mode via ant devmode (with my main server already up in another terminal). The code server launches fine, and I click my “Dev Mode On” bookmarklet in Chrome. Compilation proceeds without errors, but then DevTools immediately pops up saying “Debugger paused.” I didn’t set any breakpoints.

Steps I've already taken:

Disabled all breakpoints in Chrome DevTools (Sources ➤ :red_circle: Deactivate Breakpoints).

Cleared any marker breakpoints in my code editor.

Toggled Dev Mode off and back on again, but now I just see a blank screen.

Logs from the terminal during this process:

[java] GET /sourcemaps/ode/D4A92ECC870BD56410DE88EB04617475_sourcemap.json
[java] sent source map for module 'ode' in 169 ms
[java] GET /recompile/ode
[java] Job com.google.appinventor.YaClient-dev_1_2
[java] starting job: com.google.appinventor.YaClient-dev_1_2
[java] binding: locale=en
[java] binding: user.agent=safari
[java] skipped compile because no input files have changed
[java] 0.108s total -- Compile completed
[java] GET /sourcemaps/ode
[java] [WARN] ignored get request: /sourcemaps/ode
[java] [WARN] not handled: /sourcemaps/ode

Here’s a useful resource I referred to while trying to resolve this issue:

As you can see in the screenshot below, I’ve already added that file to the debugger’s ignore list, but the issue still persists.

Any guidance or troubleshooting steps would be hugely appreciated!

It seems like the reason it is breaking there is because of the assertion failure. Looking at the local variables in the sidebar style_0_g$ is undefined.

I’m only hitting this error in Super Dev Mode—style_0_g$ is undefined there, so the assertion fails. If I do a full compile (e.g. -Dskip.ios=true), the CSS resource loads fine and I don’t see any issue everything seems to be working as expected. But using Super Dev Mode is definitely better, since doing a full compile for even small changes like CSS is time-consuming.

Can you help me understand:

Exactly what style_0_g$ represents under the hood.

  • Local
  1. this: UiStyleFactory_OdeUiBinderNeoImpl$Widgets_1_g$
  2. style_0_g$: undefined

Are the changes you testing all up on your draft PR?

Yes, all the changes I’ve tested are pushed to my draft PR.

If you're running into assertion errors here is what i did in order to solve this issue:

The issue stemmed from the way we handled CSS resource injection in Ode.java. Specifically, we had this line:

@UiField(provided = true)
static Resources.Style style;

This field is meant to allow GWT's UiBinder to apply CSS styles to UI components. The provided = true annotation tells GWT, “Don’t instantiate this—I’ll take care of it.” But here's the catch: GWT expects that field to be properly initialized before it starts building the UI.

In our original code, we were creating a local variable style, but completely forgot to assign it to the static field. So although the CSS resource was available, it wasn’t correctly passed along to UiBinder. The missing assignment looked like this:

// Correctly assign the initialized style object
Ode.style = style;

:mag: Why this matters:

  • If you mark a field with @UiField(provided = true), GWT assumes it’ll find a usable, non-null instance at runtime.
  • If that field is null, GWT throws an assertion error, which can appear as a frustrating "Debugger paused" or blank screen in Super Dev Mode.
  • By assigning Ode.style = style; before any UI construction, you ensure UiBinder has what it needs to do its job properly.
  • This small but crucial step prevents the invisible breakpoint and lets Super Dev Mode run smoothly.

For others facing this headache: double-check any @UiField(provided = true) declarations and make sure their values are properly initialized before UI components are created. GWT won't do it for you—and if you skip this, it’s like handing it an empty paintbrush when it’s supposed to style your app.

Hope this helps someone save hours of debugging!