Found in GWT Release: 1.5.3, 1.6.1

Detailed description: I'm building a GWT app that is running under the Adobe Air runtime. Air has a WebKit browser build in. At runtime I get an exception, which originates from WebKit: 'Syntax Error: Expression Too Deep'. After a few hours of research, I've found that it is caused by the line of Javascript which GWT generates to internalize strings; I believe this is the first line of the javascript: something like this. <script><!-- var $intern_3 = '', $intern_279 = '\n', ..... etc...

The problem is that the line is too long; in my case it's just over 32k (in DETAILED mode). I also get the problem when in OBFUSCATED mode, where the same line is about 20k long; maybe it's todo with the number of variables being declared rather than the length of the line.

Workaround if you have one: The workaround requires me to manually edit the javascript produced by gwt, so that this line is split across multiple lines. Obviously this is quite inconvenient.

Links to the relevant GWT Developer Forum posts:

I've found that the issue can be workaround by compiling in PRETTY mode, which will do me fine for now.

This issue seems to have more to do with the Adobe Air Runtime rather than the JS produced by the GWT compiler (both Chrome and Safari work fine with GWT generated JS in both OBFUSCATED and DETAILED mode).

I suggest filing this at the link below: http://adobe.com/go/wish

Same here, same workaround (compile in -style PRETTY).

I don't know however if it's because of WebKit or the JS engine, as it appears only in AIR 1.5 and 1.5.1, which has switched to using Squirrelfish instead of Tamarin. And as a side note, Safari 4 is OK with the JS generated by GWT (AFAIK) because it doesn't use Squirrelfish but Nitro (previously known as Squirrelfish Extreme).

I didn't think it could be a "statement length" issue though...

Thanks, I will report it to Adobe as an issue. However, I'm guessing the likelihood and ease of getting this modified in GWT is much greater than any fix in the Air browser. I'm also guessing that it would be fairly trivial to put some additional checks in the GWT compiler to prevent an excessive number of variable decls on the same line. My code stops working when about 1045 variables appear on the same line;

I'm really hopeful this can be fixed in GWT: The app I'm writing is a desktop client for Twitter, and as I'm a big fan of GWT I'd love to be able to complete the project using GWT, and preferably with the code obfuscated. Otherwise I shall probably rewrite from scratch using Flex or something.... Thanks,

I noticed that this issue seems to be closed, without any resolution. I'm disappointed. Is there a way to get this re-opened or reviewed by a Project Owner? It really makes no sense to me that the GWT would want to limit its compatibility with other browsers when fixing this problem is, I expect, a relatively minor undertaking.... Thanks.

As per the latest comments, I'm re-opening for investigation. Sorry for the couple days of inactivity on the issue, it hadn't been actioned on since last comments because I just now got a chance to take another look at it.

I'm not sure that this is a trivial fix, and it would probably involve a bunch of special casing in the GWT compilation process. It also seems like this is outside the scope of the browsers GWT supports. But if this issue is actually caused by the JS engine used (e.g. SquirrelFish versus Tamarin), then this might be worth investigating down to a fix.

Should consider for a 1.6 update.

brilliant! Thank you :)

I am also running into this issue with the AIR 1.5 runtime. Initially I was able to work around it with a PRETTY compile. The project has a large number of classes and after adding some new classes yesterday it's now failing with the same "Expression too deep" error near the end of the generated HTML file. It's a single line generated by the GWT compiler that declares a bunch of class literal vars by stringing the declarations together with commas. I am currently working around it by doing a string replace on the line to make them individual var declarations separated with semicolons (still on the same line though).

I found where it generates the error in the public WebKit source and it seems that the JavaScript byte code generator has a hard coded limit of 10000 nodes while it's processing a single statement. So it's not really the length of the line that's the issue but the amount of internal byte code that a single statement generates.

Just as a temporary / quick fix I changed visit(JsVars x, JsContext ctx) in JsToStringGenerationVisitor to limit the max number of variables declared in a single statement to 100 and that seems to resolve the problem. Not a complete fix because you wouldn't want to break up the var statement inside of a for statement for example. There's probably other places it might cause an issue as well, not sure. Maybe it gives some insight on what a real fix might be though.

I'm getting this error now using Safari 4 Beta in our app at http://www.clarityaccounting.com ... Launch the demo in Safari 4 Beta and you'll see what I mean (tested in Window Safari 4 Beta 528.16)

Strangely, this cropped up recently when I upgraded to GWT 1.6.4. Previously with 1.5.3 I didn't have this problem. I'm not sure if this is directly caused by GWT 1.6.4 or if I simultaneous crossed some threshold, but our Safari early adopters are having problems.

Using PRETTY might be an option, but doesn't that hurt performance a lot? I wouldn't want to hurt everyone else's performance to support the few Safari 4 users ... so I'm hoping there's a better workaround.

If anyone on this issue report could boil this down to a reproducible code snippet, that would be a great help in working out a fix.

I saw this once on an internal application, but then it seemed to magically go away, so I've not been able to reproduce it again recently.

Looks like we were stepping across a threshold in the new JSCore bytecode compiler. The specific error I saw was "Syntax Error: Expression Too Deep", as someone else mentioned earlier. It appears to happen whenever we cross an expression-length threshold in JSCore. A quick codesearch (I love codesearch) yields some context (see the following url):

http://www.google.com/codesearch/p?hl=en#YwaaF8DorRY/deps/third_party/WebKit/JavaScriptCore/bytecompiler/CodeGenerator.h&q=emitThrowExpressionTooDeepException

   RegisterID* emitNode(RegisterID* dst, Node* n)
   {
       // Node::emitCode assumes that dst, if provided, is either a local or a

referenced temporary. ASSERT(!dst || dst == ignoredResult() || !dst->isTemporary() || dst->refCount()); if (!m_codeBlock->lineInfo.size() || m_codeBlock->lineInfo.last().lineNumber != n->lineNo()) { LineInfo info = { instructions().size(), n->lineNo() }; m_codeBlock->lineInfo.append(info); } if (m_emitNodeDepth >= s_maxEmitNodeDepth) return emitThrowExpressionTooDeepException(); ++m_emitNodeDepth; RegisterID* r = n->emitCode(*this, dst); --m_emitNodeDepth; return r; }

Note that it's the "return emitThrowExpressionTooDeepException();" that's the source of our troubles.

Do you think that if I found some long lines and put a few newlines in there it would fix the problem? If so I could use this as a workaround until someone fixes it more permanently somewhere.

From what I noticed, it appeared that it wasn't long lines per se, but extremely large expressions. I've seen two expressions trigger this: 1. The constant variable list near the top of the compiled output. 2. The list of class literal declarations at the bottom.

Try breaking these up into multiple var decls, as in: var a, b, c, d; => var a, b; var c, d;

I believe it has nothing to do with line length (so CR/LF won't help) but with "statement length".

As a side note, it will probably affect Android Cupcake too, now that it uses SquirrelFish.

(I think I didn't originally notice the issue with Safari 4 because my AIR build has some specific features --using GWT-in-the-AIR with File.browse, File.upload and DropPanel--, so I'll try to make a test case based on those differences)

Yes, breaking that initial string table up into separate var lines did the trick.
Now, how I can get this going so that I don't have to manually edit that file for Safari before it will work?

For what it's worth, this sed script can be helpful to fix it:

cp 727DBFA7240E60B076A0A328EBA280FE.cache.html 727DBFA7240E60B076A0A328EBA280FE.cache.html.bak

sed "s/',([A-Za-z0-9]+)='/';var \1='/g" < 727DBFA7240E60B076A0A328EBA280FE.cache.html.bak > 727DBFA7240E60B076A0A328EBA280FE.cache.html.fix

Nice digging, Joel! Looking at the nodes data structure in a nearby file to the one you point to, it looks like a vars statement is encoded in a way such that the depth of the AST is roughly twice the number of variables in the statement. Looking at the line you point to, the limit on the depth is 10,000 nodes. As a result, any vars statement with more than about 5,000 nodes is going to trigger this limit. We have verified this by generating some test files and then loading them into Safari 4; right at 5000 variables the error message starts appearing.

A simple way to fix this would be to have a JsVisitor go through and break up any super-long vars lines so that they have a maximum of, say, 4900 variables in each one. Since only ~6 characters are added per breakup, it is probably worth enabling this by default and not bothering to enable it only for Safari.

A vars-splitting fix is committed at r5459.

One of the review comments notes that this could still bite us in other contexts than long vars lines. If that's an issue in practice, e.g. with very long chains of + operations on strings, then we might need to implement a more general solution.

We just got bit by this yesterday with the official release of Safari 4 (the Safari 4 Beta worked fine). This is a huge issue for us as we are pretty much dead in the water with respect to Safari users. Is there any chance of getting a 1.5.4 patch release containing this fix?

Thanks!

Comment deleted

Our project also stopped working with official Safari 4. We're on GWT 1.6.4.

We're currently working on a 1.6 update that will deal with this and full IE8 support as well. We'll post on the public fora as soon as it's ready ("real soon now").

We would love to upgrade to 1.6. Unfortunately there are some breaking changes for us (specifically the new HasValue interface collides with some of our own databinding methods) and the the new project structure requires us to re-do our build scripts. So the upgrade is not trivial, unfortunately. I am sure this is the case for other users as well. Is there any chance to get an update to 1.5?

Regarding your build scripts, you can continue to use the GWTCompiler and GWTShell entry points rather than the new ones added in 1.6 (though they may go away in 2.0).

Don't mean to reiterate the other comments, but our project also stopped with the new release of Safari 4. It worked fine with Safari 4 Beta. We're running 1.5.3 about to update to 1.6.4.

Here's a workflow that I'm using now:

1. Compile in PRETTY
2. grep 'safari' *.nocache.js
3. Copy the indicated *.cache.html file(s) to a safe location
4. Compile in OBFUSCATED
5. Open the app in Safari 4 to figure out which *.cache.html file(s) it is using
6. Copy the PRETTY files I previously copied away over those files
7. Feel glad I worked around the issue, but wish fervently for the next release of GWT to come as soon as possible.

Just finished implementing the above workaround and it works fine (thanks!) except in one case. If I ever tried to refresh a page in Safari, the entire browser crashed. It could be something in my code, but I have never had this problem before. Anyone else with this problem?

ping! Any updates on this issue from the GWT folk? thanks..

You mean, apart from being already fixed on the SVN?

i guess i mean the update to 1.6 that includes this fix.

Hi Joel & Bruce & ??? What are you waiting for to release an 1.6.5 update ? Our application (and many other large scale applications) aren't working anymore under Safari 4 (I know, it's fundamentally a Safari issue...). Workarounds are not realistic with a large number of i18n permutations.

Thanks,

Luc

Still waiting for fix to be released...

With the 1.7 release, my GWT project runs under Safari 4, but still does not work with Adobe AIR 1.5.1. The status says this fix has not yet been released, although it was submitted well before 1.7 was released. Not sure now if it'll ever work on AIR 1.5!

@alxdark: Are you getting the exact same error, or could it be failing on Air for other reasons? Air is not part of our normal test suite (it's already quite large), so it's not inconceivable that something else could have slipped by, especially if they've done anything strange to their WebKit build.

We know that we fixed the too-long-line issue that relates to the later WebKit version (it's the Javascript VM, to be precise). To see if this actually is the problem you're experiencing, try adding this configuration property to your module:

The default's 2400, which is well under the limit in the Nitro Javascript engine, but perhaps Adobe configured it differently. If this doesn't fix the problem, then it's most likely an unrelated issue.

@jgw: I'll try this and report back. I believe it is the same issue because the error message is the same at runtime: 'Syntax Error: Expression Too Deep'.

The 'compiler.max.vars.per.var' property fixes the build on AIR 1.5.1, thanks so much for your help! For those who have a similar issue, the largest value I was able to use for this (assuming that longer lines are better) was 995.