@dom_walden :

When I tried to access the links provided, the articles appeared to load fine (see some examples below). Could this be because I first accessed them before enabling WWT (even though I cleaned the cache before accessing the again)?

@ifried Are you using the gadget? I was using the extension. I tried briefly with the gadget, but could not reproduce either.

@dom_walden Ah, thanks for the clarification!

@Mooeypoo This bug may only be reproducible with the extension rather than the gadget. Do you know why that may be?

In T232460#5505012, @ifried wrote:

@dom_walden Ah, thanks for the clarification!

@Mooeypoo This bug may only be reproducible with the extension rather than the gadget. Do you know why that may be?

Nooo... but... it is very interesting.

Language blob is just an object, it *should* work. And since the extension injects the script into the page, it *acts* like a gadget.

... so I have no idea why it doesn't load, but the fact it's only happening with the extension is useful as a starting point, for sure.

@dom_walden I just re-tested this in an effort to figure out what's going on, and I can no longer reproduce it...

Can you retest? I tested both the extension and user script.

If you want, I have the user script on my userpage, you can load it on the supported wikis by putting this in your /common.js

// WhoWroteThat test
mw.loader.load( 'https://www.mediawiki.org/w/index.php?title=User:MSchottlender-WMF/WhoWroteThat.js&action=raw&ctype=text/javascript' );

(Just beware of loading it alongside the extension; if both load it might cause conflicts)

I can't reproduce it anymore... We have no translations yet, so it looks weird (especially since it's forcing RTL for an English text) but the code runs fine, and everything works. I was testing on this: https://en.wikipedia.org/wiki/William_Hayden_English?uselang=he

In T232460#5510255, @Mooeypoo wrote:

@dom_walden I just re-tested this in an effort to figure out what's going on, and I can no longer reproduce it...

Can you retest? I tested both the extension and user script.

With commit 090bf2462268873f10b39a22caf5017cce7c3082 of WWT, I could reproduce on Chromium 73 (Debian) and Firefox 69 (Win10) with https://de.wikipedia.org/wiki/Bertha_Lamme?uselang=he and on Chromium 76 (Debian) with https://de.wikipedia.org/wiki/Bethel_Township_(Clark_County,_Ohio)?uselang=ar (the previous link worked ok on 76).

Could this have been related to the bundled jQuery? I can't reproduce it with current master (which is now without jQuery).

I had this issue when I tried https://eu.wikipedia.org/wiki/Thorichthys_ellioti?uselang=fr (on master) in Chromium. @ifried is reporting similar issues with the deployed Firefox extension.

After enabling the beta Firefox add-on, I received the following message on Wikipedia pages: "A web page is slowing down your browser. What would you like to do?" Am I doing something wrong?

This is (sometimes!) reproducible with by launching the extension in Firefox with

./node_modules/.bin/web-ext run --start-url https://de.wikipedia.org/wiki/Bertha_Lamme?uselang=fi --verbose

and then changing the uselang=fi to uselang=he, and sometimes again to other language codes. At this point it hangs and the following three errors are in the log:

[firefox/index.js][debug] Firefox stdout: Extension error: TypeError: result is undefined moz-extension://a6207eb4-1b52-402a-9c45-38a4cb2477f6/js/contentScript.js 36
[[Exception stack
activateWelcomeTour/<@moz-extension://a6207eb4-1b52-402a-9c45-38a4cb2477f6/js/contentScript.js:36:3
Current stack
applySafeWithoutClone@resource://gre/modules/ExtensionCommon.jsm:601:13
wrapPromise/</<@resource://gre/modules/ExtensionCommon.jsm:824:20
withLastError@resource://gre/modules/ExtensionCommon.jsm:743:14
wrapPromise/<@resource://gre/modules/ExtensionCommon.jsm:812:16
]]

[firefox/index.js][debug] Firefox stderr: JavaScript warning: https://de.wikipedia.org/w/load.php?lang=fi&modules=startup&only=scripts&raw=1&skin=vector, line 78: Error: Script terminated by timeout at:
@https://de.wikipedia.org/w/load.php?lang=fi&modules=startup&only=scripts&raw=1&skin=vector:78:728
@https://de.wikipedia.org/w/load.php?lang=fi&modules=startup&only=scripts&raw=1&skin=vector:78:786

[firefox/index.js][debug] Firefox stdout: Extension error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowUtils.removeSheetUsingURIString]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://gre/modules/ExtensionCommon.jsm :: runSafeSyncWithoutClone :: line 75"  data: no] undefined 75
[[Exception stack
runSafeSyncWithoutClone@resource://gre/modules/ExtensionCommon.jsm:75:12
cleanup@resource://gre/modules/ExtensionContent.jsm:402:34
close@resource://gre/modules/ExtensionContent.jsm:925:14
inner-window-destroyed@resource://gre/modules/ExtensionContent.jsm:1010:19
observe@resource://gre/modules/ExtensionContent.jsm:1028:27
Current stack
runSafeSyncWithoutClone@resource://gre/modules/ExtensionCommon.jsm:81:9
cleanup@resource://gre/modules/ExtensionContent.jsm:402:34
close@resource://gre/modules/ExtensionContent.jsm:925:14
inner-window-destroyed@resource://gre/modules/ExtensionContent.jsm:1010:19
observe@resource://gre/modules/ExtensionContent.jsm:1028:27
]]

The first of these is known, and results from the storage.sync not being available in Firefox unless an explicit extension ID is set. A fix for this is waiting review: https://github.com/wikimedia/WhoWroteThat/pull/75

When running from that branch, the above three errors do not occur, and I've not been able to reproduce this bug. It seems like it might be the error-handling of the storage bug that is causing the script to hang. I'm not saying definitively, because this bug isn't always reproducible anyway.

Occasionally the Script terminated by timeout at... error happens, but there is no observable error in the interface and everything works fine.

Let's get PR75 merged, and revisit this.

I have (annoyingly) been able to reproduce this in the following scenarios:

• With an empty languageBlob, e.g. in src/outputs/browserextension.js: const languageBlob = {};
• With all_frames: false to prevent WWT from being loaded in subframes (it is sometimes loaded more than once; but stopping that didn't solve this bug)
• Some people suggest that a11y features of Firefox can interfere with extension content-script loading; but that turning off didn't help (--pref=accessibility.force_disabled=1)
• Sometimes the welcome popup doesn't load, but the WWT link does appear in the sidebar, and does work; this is because of the load order of adding the unseen class to the page, and the checking for that class. It's a different bug, but I think may have the same underlying cause (i.e. load order unpredictability).

Whenever I have been able to reproduce this, it's not been repeatable: every immediate subsequent load of the same page has not had the bug, but sometimes going to another page and then back again does show it... but sometimes it doesn't.

If anyone has any ideas, feel free to grab this task. :(

Run with e.g.:

./node_modules/.bin/web-ext run --verbose --browser-console --start-url https://de.wikipedia.org/wiki/Bertha_Lamme?uselang=ru

I have figured out a fix. Basically, it looks like we add to the Resource Loader queue before it's finished being set up.

So a hacky fix is to spin until we can use it (checking for mw.loader.using() because that's the first thing we want to use). A PR for this is here:
https://github.com/wikimedia/WhoWroteThat/pull/117

A minimal extension example of the failure takes three little files:
https://gist.github.com/samwilson/9dc005fa5e4fe38f0eb4c65ec6609755

The upstream fix was merged (and deployed) into MediaWiki core, so this should be fixed without our quickfix. Moving to QA to verify.

I loaded random articles on en, de, es, eu and trwiki. Each wiki was on a different skin and language. Watching for any slowdowns or long-running scripts.

I also walked through the menu items for each wiki to find different special pages, portals, etc. Just in case the bug appears on non-main space pages.

This was tested on Firefox 68 and Chromium 73, version 0.12.0 installed from the Chrome Store/Firefox Addon Repo. For Firefox, I used a new profile to simulate a new user installing WWT for the first time. Previously, I found the bug happened more often when I used a new profile.

In T232460#5704166, @Samwilson wrote:

./node_modules/.bin/web-ext run --verbose --browser-console --start-url https://de.wikipedia.org/wiki/Bertha_Lamme?uselang=ru

I ran this script in a loop with a random selection of articles from all 5 supported wikis on a random selection of languages. Examined the output to see if there were any exceptions.

The script was run on Firefox 68 with commit f08aba0dcd0d7ce45e32e510fb0bd823b9a34615.

The version of WWT should not matter, because the fix has been made to MediaWiki not WWT.