Announcement

**Isomorphic** · 13 Mar 2026, 08:33

Redeclaration of vars in JavaScript is not invalid. It looks like you've turned on some kind of validation that shouldn't be on.

**eliasbalasis** · 13 Mar 2026, 20:12

It is a GWT 2.12.2 GWTTestCase throwing the error, through HtmlUnit.

I think the JavaScript should be made compatible, otherwise we cannot examine SmartGWT functions in our GWT tests.

**Isomorphic** · 13 Mar 2026, 22:41

It is compatible- again you’ve turned on some kind of ultra-strict validation where common JavaScript usage (which works in browsers, Node.js etc) is being treated as a fatal error.

This is not normal nor is it the default.

Turn that back off and you’ll be fine.

**eliasbalasis** · 2026-03-14T10:55:43

I have turned the validation off but the JavaScript execution by JavaScriptEngine of HtmlUnit, on which GWT testing depends, is failing.

Therefore, from where I stand, it is logical to suggest that SmartGWT does not feel compatible with the GWT testing framework.

Looking back to past incidents, I appreciate that using GWT Test Case with the HTMLUnit pseudo-browser is rather discouraged due to possibility for false positives and use of a real browser is advisable instead.
see https://forums.smartclient.com/forum...011#post268011

However, even though it seems to be the general SmartGWT direction, transforming our testing frameworks to support a real browser has turned out to be quite difficult, because GWTTestCase must be translatable to JavaScript and cannot carry any programmatic initialization that would create and connect a real browser.
Besides we are only testing client-side APIs (like Criteria) not widgets and use of a real browser should not be necessary.

Please understand that this is not a common problem and the demand for using a real browser is shooting us on the foot, which begs the question, would it be possible to make the JavaScript compatible with the HtmlUnit JavaScript engine ?

I will try to find a solution in the meantime so that we can use a real browser without too many complications.

**Isomorphic** · 2026-03-14T20:08:22

Once we correct these fake errors that do not happen in any real browser, should we await the next batch of fake errors and fix those too?

And then if your tests pass, does that even mean anything?

We are definitely not interested in trying to add support for a fake browser where neither test failures nor test successes can be trusted.

If this somehow really, really matters for you, you can buy a block of consulting hours so you can report fake bugs and we'll fix them anyway. But we will not be adding general support for a fake browser - this is why we document it as unsupported explicitly.

Notes:

1. from a quick look, these errors come from a known bug in Rhino. There is nothing wrong with SmartClient's JavaScript. Our usage is correct.

2. it is really easy these days to set up real browser automated tests, and since you'll need to do that no matter what for visual tests, we can't see any point in having a second set of tests in a fake browser

**eliasbalasis** · 2026-03-14T23:55:04

Like I said, we understand the SmartGWT direction towards using a real browser.

Therefore, we had to build a method that makes use of a real browser in our GWT tests and we won't be needing further help.

It wasn't as hard as we initially thought.

Announcement

Errors in JavaScript files on v14.1p_2026-02-20

Comment

Comment

Comment

Comment

Comment

Comment