Syntax error message


We’re suffering from a weird bug that doesn’t occur reliably. Only one of our developers has been able to reproduce it, but unfortunately our most important customer sees it all the time. Here’s a dropbox link to the error we get:

There’s no Java stack trace, so it’s been very difficult to find. It only seems to occur with FireFox, other browsers are not affected.

In our project we have first public web pages. Vaadin forms the Intranet. Some of the pages are the same as on the public side, so they are duplicated as embedded jsp pages rather than redoing them with Vaadin. This error always occurs when navigating from a jsp page to a Vaadin page. Links to do this look like this:

UriFragmentUtility catches the request and displays management for the requested element. This is an entirely Vaadin page. Our most recent test was to remove the # and let URIHandler handle the redirection, but that one seems to cause the same error.

I can provide a link to our test server as well as any relevant parts of our source code if anyone could have a look. I can’t post the url publicly, but can offer limited time access to test this bug if anyone can help.

Just received more information. One of our devs who manages to get the bug occasionally is getting the following error in his log: “Warning: Ignoring variable change for non-existent component, VAR_PID=PID4”.

No clue as to what that means.

Even more information.

On FireFox, clicking the link causes first a reload of the old page, only after that we get a call to fragmentChanged(). The reload is the one that causes the warning log and the error message.

On Chrome, the very first time the link is clicked, there’s also a reload of the old page first, then the call to fragmentChanged(). On subsequent tries, the fragment event happens immediately. No crash though, even on the first try.

On IE the same bug appears if we remove the # and try to use a UriHandler.

The warning and bug always appear before any calls to UriHandler or UriFragmentUtility. Is there any way to prevent the extra loading, or at least cause it not to crash?

The log warning could be unrelated. It appears to be a synchronization problem, for example if you have two browser tabs or windows open to the same application and do not handle that properly. It could show as “Out of Sync” error in the browser.

The red “Communication Error” box seems to usually occur when a “Session Expired” error should occur. It seems to occur typically in Vaadin applications running in Liferay. In that case, the solution is the same as for session expired errors generally: 1) increase session timeout to a higher value or 2) add keep-alive polling to the application.


Session timeout has been set to half an hour for about a year and a half. We can get the error within a minute of starting and we’ve got a rather large site where everything else works properly. So I don’t think the session in timeouting, though I appreciate your effort.

We’ve been investigating further, and the following occurrences seem to be happening:

With a link that has ourSite#/link FireFox gets a URI event first, reloads the old page and throws the error. Clicking on the error gives the fragment event and proceeds to the correct page. Other browsers work, although on the first try at least Chrome does a reload of the old page (due to a URI event) before proceeding with a fragment event. Subsequent tries with Chrome no longer do the reload until you close & restart the browser.

With a link that has ourSite#link FireFox works properly. Only a fragment event is given. However, IE fails to work at all.

Looks like the sampler uses urls of type site/#link. Maybe that’s the key. Going to try on Monday.

Ok, I’ll just answer myself since we finally solved the bug. Having a link like we had causes the problem in roughly 20% of FireFox browsers that we’ve experimented with:

<a href="/ourSite#/manageElement?id=11707" class="" target="_top">

The #/ causes a URI event before the fragment gets evaluated and for some reason on some FireFoxes, this leads to the error message. By using just # the problem goes away:

<a href="/ourSite#manageElement?id=11707" class="" target="_top">

All tested FireFoxes will do only the fragment event, therefore no errors.