Wt

Do you have any additional information? Does your browser's debugger show anything special?

Maybe a clean rebuild solves the problem?

Best regards,

Wim.

Wim Dumon wrote:

Do you have any additional information? Does your browser's debugger show anything special?

Maybe a clean rebuild solves the problem?

Best regards,

Wim.

How info need for you? Also, if I disable java in chromium, i can see "Hello Word!");

Clean rebuild dont solve problem.

So, i try build Wt from source (3.3.5-rc1) - nothing.

I have the same problem (debian testing, wt 3.3.4+dfsg-3).

Firefox:

SyntaxError: expected expression, got '}'

Chromium:

Uncaught SyntaxError: Unexpected token }

Original loaded JS is in the attachment. Syntax error in line 7.

Syntax checker on beautified script shows:

} else if (newHash !== hash) {
    hash = newHash;
    _updateIFrame(newHash)
}
}, 50);  // <- "Unexpected token }" reported here
_initialized = !0;
null != _onLoadFn && _onLoadFn()
} else setTimeout(_checkIframeLoaded, 10)
}

I looked again at the code and it seems that the script gets messed up by a comment (look for "//#"). To me, having a comment in such a compressed script seems odd.

Sadly, I am not familiar with javascript and the intestinals of Wt, so I don't think I can help much further.

Hey,

This '//# sourceMappingURL=jquery.min.map}' was added by your browser, ASFAIK. At least it's not anywhere within Wt or it's skeletons.

What browser are you using and do you get it with all browsers?

Apparently, this is generated by some minifiers (not the one that we are using), so it may be that there are people repackaging Wt (and introducing this bug?).

Where did you download your Wt version from?

Koen

I doubt the comment is an artefact of the browser, since I get the same error messages in both Firefox and Chromium.

The error occurred in 3.3.4+dfsg-3, now I'm using 3.3.4+dfsg-4 and having the same problem. Both are from the debian testing repositories. I also thought about this being a packaging-problem, since everybody experiencing it so far uses debian testing.

ioann said the problem was not solved by building wt from source (I didn't try myself), so may this come from some issues outside of the scope of wt (e.g. external minifier), that is specific to the distribution?

I checked out the source from the debian repository, and the only thing similar are the

/*# sourceMappingURL=bootstrap.css.map */

What tools are used and what is the "reference" version? I saw some commits about uglifyJS switching major version in the debian repositories:

+  * Detect UglifyJS < 2.x and > 2.x and provide different arguments to the
+    minifier (required to support older Ubuntus)

+  * Adapt uglifyjs parameters to new uglifyjs version (Closes: #769215).

+  * Fix minifier detection logic in debian/rules. Closes: #754662
+  * Change dependencies in debian/rules to use list of architectures where
+    nodejs is available rathe than incomplete list of architectures where
+    it is available.

Might this be related to the problem?

At which stage is the javascript actually minified? Compilation/installation of wt, compilation/runtime of the program?

The files are actually minified by us (since we are aware of possible issues, and we didn't want the minifier toolchain to become dependency for building Wt) and thus minification is not part of the build. In the past we have been aware of debian package maintainers re-minifying the files themselves because of debian policies (everything must be build from source, including minified files).

None of our minification tools add this 'sourceMappingURL' (we use an older version of google closure compiler).

So I think that indeed the debian package maintainers should be notified of this problem.

I added a link to this discussion to the debian bug tracker. Apparently, this bug has already been filed at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798332, but the corresponding forwarded upstream-bug at http://redmine.emweb.be/issues/4462 has a completely different problem description.

Hello,

Debian maintainer here. I will look into this right away.

Could you please tell me what architecture are you using? The Debian package uses uglifyjs on some architectures and yui-compressor on others (where uglifyjs is not available).

I'm on 4.1.0-2-amd64 #1 SMP Debian 4.1.6-1 (2015-08-23) x86_64 GNU/Linux

Wt 3.3.4+dfsg-4 migrated to testing yesterday. Could you please upgrade and check if the problem persists? So far, I have been unable to make this fail (but I am currently testing on Ubuntu Willy).

As I said previously, I already updated to dfsg-4, the problem still exists.

Where are the minified scripts located? I haven't found anything with this content neither in /usr/share/Wt/resources nor in the repository.

The are built into the library. In the source tree they are located in src/web/skeleton

I have tracked down the problem to jquery.min.js from libjs-jquery, version 1.11.3+dfsg-3

That package contains this:

$ ls -lah /usr/share/javascript/jquery

total 580K

drwxr-xr-x 2 root root 4.0K Sep 23 00:51 .

drwxr-xr-x 4 root root 4.0K Sep 23 00:51 ..

-rw-r---r--- 1 root root 278K Aug 29 03:46 jquery.js

lrwxrwxrwx 1 root root 13 Aug 29 03:46 jquery.lite.js -> jquery.min.js

-rw-r---r--- 1 root root 144K Aug 29 03:46 jquery.min.js

-rw-r---r--- 1 root root 148K Aug 29 03:46 jquery.min.map

lrwxrwxrwx 1 root root 13 Aug 29 03:46 jquery.pack.js -> jquery.min.js

Where jquery.min.js is obtained by uglifying jquery.js. Extract from jquery-1.11.3+dfsg/debian/rules:

dist/jquery.min.js dist/jquery.min.map: dist/jquery.js

uglifyjs \

---source-map dist/jquery.min.map \

---source-map-url jquery.min.map \

---output dist/jquery.min.js \

$^

There are at least two problems there:

jquery.min.map should not be distributed in the first place

jquery.min.js contains this at the very end:

[...]

"jquery",[],function(){return jQuery})}var jQuery=window.jQuery,$=window.$;jQuery.noConflict=function(deep){if(window.$=jQuery){window.$=_$}if(deep&&window.jQuery=jQuery){window.jQuery=_jQuery}return jQuery};if(typeof noGlobal===st

rundefined){window.jQuery=window.$=jQuery}return jQuery});

//# sourceMappingURL=jquery.min.map

See that comment? Remember it

When Wt builds, jquery.min.js, Wt.min.js and Boot.min.js are converted to C by the filetostring.cmake macro called in src/CMakeLists.txt. This generates JQuery_js.C, Boot_js.C and Wt_js.C.

The extraneous comment in /usr/share/javascript/jquery/jquery.min.js results in this in JQuery_js.C:

"jquery\",[],function(){return jQuery})}var jQuery=window.jQuery,$=window.$;jQuery.noConflict=function(deep){if(window.$=jQuery){window.$=_
$}if(deep&&window.jQuery=jQuery){window.jQuery=_jQuery}return jQuery};if(typeof noGlobal===strundefined){window.jQuery=window.$=jQuery}return jQuery});\r\n\"

"//# sourceMappingURL=jquery.min.map";

std::vector<const char *> JQuery_js()

{

std::vector<const char *> retval;

retval.push_back(JQuery_js1);

retval.push_back(JQuery_js2);

retval.push_back(JQuery_js3);

return retval;

}

}

When Wt generates JavaScript and that comment gets in the middle, it causes errors.

Therefore, I think the problem boils down to bad minification of jquery.js in the libjs-jquery package.

I will report the bug

Ok, thanks for the solution!

Due to the general possibility of comments in the scripts, maybe it would be a good idea to have a new line for every file that is concatenated into one? As far as I know, the debug version uses unminified scripts, where there might be comments not only in error-cases.

The jQuery maintainer in Debian has already fixed the issue and uploaded a new version of his package.

As soon as it's generally available in the archive, I will rebuild the Wt packages.

All in all, it will take around 9 days from now for the fix to reach you.