"jquery.uls.data" syntax error in IE11
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	Krinkle
	Dec 2 2016, 4:29 AM

Description

On all page views in IE 11, the following error is logged to the console:

Exception in store-eval:
SyntaxError: Expected ';'

I can reproduce this in BrowserStack using Windows 8.1 and IE 11 on mediawiki.org, en.wikipedia.org and localhost (MediaWiki-Vagrant).

Narrowing it down I find the following:

It only happens when loading code from localStorage. When running localStorage.clear() the first page view is fine.
It comes from the "jquery.uls.data" module. (Patches mw.loader#asyncEval to run globalEval in a for-loop and log the first part of each string.)

Screen Shot 2016-12-01 at 20.25.10.png (513×351 px, 114 KB)

This means that in IE 11, users are stuck in the following loop:

First view loads JS from load.php and populates localStorage.
Second view loads modules from localStorage, until ULS is reached in the list of modules. Error is caught. localStorage is cleared. Rest of the modules are loaded from load.php.
Third page is as the first view.
Fourth page is as the second view, etc.

jquery.uls.data:

Related Objects

Mentioned In: T90524: Use source urls in mw.loader.store

Event Timeline

Krinkle created this task.Dec 2 2016, 4:29 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 2 2016, 4:29 AM

Krinkle mentioned this in T90524: Use source urls in mw.loader.store.Dec 2 2016, 4:30 AM

Krinkle triaged this task as Unbreak Now! priority.Dec 2 2016, 4:33 AM

Krinkle updated the task description. (Show Details)

Restricted Application added subscribers: Jay8g, Luke081515, TerraCodes. · View Herald TranscriptDec 2 2016, 4:33 AM

Any idea what is the cause? jshint only gives: 6 This character may get silently deleted by one or more browsers.

There has been only few recent changes to these files, neither of them change the structure in an significant way, and the data file is autogenerated anyway.

If this is a regression, can you find out which revision it started happening?

Aside, I won't be back to work until next Wednesday.

KartikMistry subscribed.Dec 3 2016, 11:45 AM

I tried reproducing this and didn't succeed. I tried with IE 11 on Windows 7, logged-in and logged-out, with Compact Language Links on and off.

I cannot see any errors on the JS console or any other breakage. I tried loading several pages, and they were all OK.

I do see one thing, although it's probably not the problem: If I open an English Wikipedia page with ?debug=true, I see the long auto-generated line in jquery.uls.data.js cut a few characters short. If should end with "ZW":["sn","en","ny","ve","tn"]}};, but it ends with "ZW":["sn","en","ny","ve",". It might be just a problem with IE's JS source viewer. The data is loaded correctly if I inspect the $.uls.data variable.

If this still happens, can anybody please write more detailed instructions to reproduce? Specifically:

logged-in or logged-out
to which pages to navigate
is the Compact Language Links beta feature enabled or not

Some other thoughts:

A recent change in this file is the addition of the sty language. It's actually added manually to a yaml file, and then the JS and JSON files are auto-generated.
Maybe the line became too long?
Niklas mentions a "This character may get silently deleted" error. I found where it is: in the autonym of the Laki language the code of which is lki. It was added to yaml two years ago. I committed a change to langdb that removes this character because it's definitely unnecessary, although I'm not sure that it will resolve this issue.

I tried to reproduce in browserstack, I did not see any error reported by browser console even after trying multiple reloads with debug=1 or debug=false

As Amir said, I noticed truncated jquery.uls.data in the debugger of IE11 debugger

But when used the pretty print tool in debugger, I get

So, the debugger is not reliable here :/

• Gilles added a project: Performance-Team.Dec 14 2016, 6:42 PM

I'm still able to reproduce this on the first attempt:

Open BrowserStack (Windows 8.1; IE 11 Latest)
https://www.mediawiki.org (first view)
Open Developer Tools
Make a second view (e.g. click logo, or any other page link)

Screen Shot 2016-12-14 at 11.54.40.png (486×1 px, 213 KB)

After this point the ULS interface does work fine, but that is because if an error happens during the loading of a module from local storage, it will clear the cache and instead fetch the module from the server via load.php.

I can reproduce the same on https://en.wikipedia.org and locally (MediaWiki-Vagrant).

In T152180#2846114, @santhosh wrote:

I tried to reproduce in browserstack, I did not see any error reported by browser console even after trying multiple reloads with debug=1 or debug=false

I consistently get it on all secondary views with debug disabled. This confirms the hypothesis of the bug being triggered only when the code is loaded from localStorage (debug mode bypasses localStorage cache, and on first non-debug view the cache would still be empty).

• Gilles moved this task from Inbox, needs triage to Radar on the Performance-Team board.Dec 15 2016, 9:30 PM

Nemo_bis subscribed.Dec 18 2016, 4:19 PM

OK, I did manage to reproduce it with BrowserStack, although I'm still mystified about several things:

If it can only be reproduced with BrowserStack, maybe it's a particular problem there?
Is there a good reason to minify jquery.uls.data the way we do? Maybe IE has a problem with the very long line in that auto-generated file? Maybe we can just put nicely-formatted JavaScript with short lines in that file and let our usual minifying tools do the rest?

These are just wild guesses—I know very little about debugging obscure IE JS bugs.

This has now been UBN! for >1 month (including holidays, but still...).

Next steps/plan here?

In T152180#2892976, @Amire80 wrote:

If it can only be reproduced with BrowserStack, maybe it's a particular problem there?

Is there a good reason to minify jquery.uls.data the way we do? Maybe IE has a problem with the very long line in that auto-generated file? Maybe we can just put nicely-formatted JavaScript with short lines in that file and let our usual minifying tools do the rest?

I don't believe this is specific to BrowserStack.
Yes, it's possible the line length is the culprit for IE's JS parser. JavaScriptMinifier in ResourceLoader maintains a maximum line-length of 1000 characters. This was introduced in 2011 for unrelated reasons, but it's possible that it also helped prevent this type of issue.

Liuxinyu970226 subscribed.Jan 19 2017, 7:56 AM

This has now been UBN! for almost 2 months, re-prioritizing to High (to get it out of my UBN! search).

Can't reproduce this issue anymore.

Liuxinyu970226 unsubscribed.May 29 2017, 4:17 AM

	F5055738: Screen Shot 2016-12-14 at 11.54.40.png
	Dec 14 2016, 7:56 PM

	F4935156: Screen Shot 2016-12-01 at 20.25.10.png
	Dec 2 2016, 4:29 AM

	F4980921: pasted_file
	Dec 5 2016, 5:21 AM

	F4980924: pasted_file
	Dec 5 2016, 5:21 AM

	F4980918: pasted_file
	Dec 5 2016, 5:21 AM

"jquery.uls.data" syntax error in IE11Closed, ResolvedPublicActions

Description

Related Objects

Event Timeline

"jquery.uls.data" syntax error in IE11
Closed, ResolvedPublic
Actions