The website hangs sometimes

[swedebugia]

I find that it suddenly becomes unresponsive. Reloads does not help. Closing the tab and reopening seems to help.

[Nudin]

When this happens, can you take a look at the browser console and page any errors/warnings here?

[swedebugia]

Will do 👍

[Daniel-Mietchen]

It just happened to me, and I got

TypeError: newLangStr is null

Screenshot attached. At that point, I also noticed that the about two dozen or so lexemes I had curated before that one did not result in any edits.

[Daniel-Mietchen]

Update: the above-mentioned edits came in with about an hour of delay (sample edit matching the screenshot above). Not sure what caused that — has the webservice been restarted?

[Nudin]

1. I found and fixed the bug that caused the TypeError you saw. That was triggered when one clicks the other languages button and then cancel in the dialog. Fixed it, but that should not cause the tool to become unresponsive.

2. The edits that only were saved after an hour: The backend that creates the edit on Wikidata has a mechanism that edits won't be done if the server is already under high load. The parameter when this happens maxlag was set to the prescribed value for bots. Since this isn't a bot I can set is considerably higher. I just did that (from 5 to 18), so this behavior should only occur in rare cases when the servers of wikidata are extremely overused. But this again should not cause the site to become unresponsive.

Do you remember what the last action was before the site went unresponsive? And how is does this unresponsiveness become visible (only the tree man-buttons don't work or do the lanuage chooser also not work anymore)?

[Daniel-Mietchen]

Ad 1: thanks.
Ad 2: makes sense.

On topic: I just gave it another try, and it took much longer than (recently) usual to get to the point when it froze. Nothing to see in terms of error messages, but the three main buttons became unresponsive, while the language selector and the other links seem to work normally. The last thing I did before the freeze was fixing the Korean gloss in the tool and the corresponding description on-wiki. However, have made similar edits on other lexemes in the same session, with no issues.

[Daniel-Mietchen]

Examples of lexemes where similar edits did not cause issues: Amboss, Biosphäre.

[Daniel-Mietchen]

Just had it freeze once more, again after having edited the description on-wiki and the lexeme's gloss in the tool, though this time, it froze on the next lexeme, again with no error messages.

As a workaround, I am opening the language selector and adding/ removing some text string (e.g. "simple", "test"), which revives the tool.

[Nudin]

I found and fixed one thing that could have been the cause. Also, I added a debug-function. In the web-console you can call it with main.debug(), it prints all the state of the tool. If the bug (or other bugs) occurs toggle open the first level of the printed objects send me it's output.

[Nudin]

Has anyone noticed another freeze since my last post? If so, please reopen!

[Daniel-Mietchen]

I can't reopen but noticed another freeze and tried to get the debug output that you mentioned above.

Interestingly, while in debug mode, the buttons became active again. Leaving debug mode, they were frozen again, but going back to debug mode again, I could actually trigger the two expected edits.

Of note, the "No match" button seemed somewhat reactive even when the others were frozen, i.e. it sometimes displayed the tooltip "Press 'n'" but did not turn blue.

[Daniel-Mietchen]

I also noticed some minutes earlier that I had the Lebensmittel example from one of the comments above again, and while it did not freeze, it did not result in edits either, even though edits to multiple other lexeme pages worked as expected.
Can't go back to the logs for that because they were apparently restarted when I switched the target language to Korean.

[Nudin]

I now found this in the logs:
"As an anti-abuse measure, you are limited from performing this action too many times in a short space of time, and you have exceeded this limit. Please try again in a few minutes."

Apparently you were editing too much too fast. ;) I'll ask on the tech mailing list, if there is anything I can do about this. I'll also add an error message to the Interface for these cases.

I am however now sure is that is the reason for the freezing or "just another" issue.

[Daniel-Mietchen]

This makes sense. I often have QuickStatements running in the background, which then results in (some) manual edits failing with such error messages, or tools (sometimes) failing without notice.

[Daniel-Mietchen]

I just got this warning:

19:10:33.221 load() 3 machtsinn.js:71:13
19:12:18.807 Source map error: Error: NetworkError when attempting to fetch resource.
Resource URL: moz-extension://257197c5-48c9-8d48-9f5b-b1fcc6b051d8/browser-polyfill.js
Source Map URL: browser-polyfill.js.map 

along with a "Learn more" link pointing to https://developer.mozilla.org/en-US/docs/Tools/Debugger/Source_map_errors .

This seems like a good candidate for causing a hang.

Interestingly, the simple act of opening the JS browser console made the buttons accessible again, as mentioned in previous comments.

As an aside, I think some more information on when to press "no match" would be useful. Here, the lexeme in question is das Tag, whereas all suggestions are a good match for one sense of der Tag. So far, I have usually skipped in such situations, but could imagine that indicating "no match" would be the better way to go. Note that the same example already came up at another ticket, and one benefit of indicating "no match" would presumably be no to run into the same suggestions time and again.

[Daniel-Mietchen]

When I clicked "Skip", I got this:

[Nudin]

I just got this warning:

19:12:18.807 Source map error: Error: NetworkError when attempting to fetch resource.
Resource URL: moz-extension://257197c5-48c9-8d48-9f5b-b1fcc6b051d8/browser-polyfill.js
Source Map URL: browser-polyfill.js.map 

This is clearly a bug in one of your browser extensions (moz-extension). You can go to about:debugging and see the tab 'this firefox' to see which extension has the id visible in the error.

Interestingly, the simple act of opening the JS browser console made the buttons accessible again, as mentioned in previous comments.

This also strongly suggests that it's something with the browser or an extension.
In your last screenshot you accidentally(?) enabled the option "Pause on exceptions" – sadly the exception isn't visible in the screenshot.

As an aside, I think some more information on when to press "no match" would be useful. Here, the lexeme in question is das Tag, whereas all suggestions are a good match for one sense of der Tag. So far, I have usually skipped in such situations, but could imagine that indicating "no match" would be the better way to go. Note that the same example already came up at another ticket, and one benefit of indicating "no match" would presumably be no to run into the same suggestions time and again.

I don't understand you here. The "reject match" does already exist for cases like this. While on 'skip' let the match will remain in the system and presented to users again, reject marks the match as wrong and it's never shown again. Why would you not press reject on such a wrong match?