Page MenuHomePhabricator

AddImage plugin sometimes does not load (Error: Your skin is incompatible with VisualEditor)
Closed, ResolvedPublic

Description

I noticed this earlier this week. I clicked on an image suggestion task from Special:Homepage, and was taken to the article page. The AddImage plugin did not load, I was stuck in "Read" mode. In the browser console, I saw this message:

Your skin is incompatible with VisualEditor. See https://www.mediawiki.org/wiki/Extension:VisualEditor/Skin_requirements for the requirements.

Reloading the page, the AddImage plugin loaded correctly and switched the page into edit mode.

Event Timeline

kostajh triaged this task as High priority.Jul 8 2022, 10:08 AM

I don't think we can determine the frequency of this bug from our existing analytics, so I am marking it high priority to investigate and fix.

Sounds more like a VE issue than a GrowthExperiments issue? VE might have analytics for this happening.

The small time window between backporting rSVECa1350cde48f5: Rename `data-ve-target-container` attribute to `data-mw-ve-target-container` and rEVED44ab552ce663: Rename `data-ve-target-container` attribute to `data-mw-ve-target-container` could have caused this, but that was on the previous week (the 28th to be exact).

Editing-team any thoughts? Do you know of any VE analytics which would let us confirm whether this is happening frequently, and whether it is specific to structured edits?

KStoller-WMF lowered the priority of this task from High to Medium.Jul 26 2022, 5:40 PM

I know nothing. We don't have analytics for this, because it was never supposed to happen in production, but maybe we should have if it does.

Last week there was also an issue with some of the servers running the wrong version of the code (T313770), which may somehow be related if e.g. some Vector config options assumed the new code was deployed, or something.

Change 817398 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/VisualEditor@master] Log incompatible skin warnings

https://gerrit.wikimedia.org/r/817398

Change 817398 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Log incompatible skin warnings

https://gerrit.wikimedia.org/r/817398

Change 818532 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/VisualEditor@master] Tighten conditions for incompatible skin warnings

https://gerrit.wikimedia.org/r/818532

Change 818532 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Tighten conditions for incompatible skin warnings

https://gerrit.wikimedia.org/r/818532

Change 819543 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/VisualEditor@wmf/1.39.0-wmf.23] Tighten conditions for incompatible skin warnings

https://gerrit.wikimedia.org/r/819543

Change 819543 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@wmf/1.39.0-wmf.23] Tighten conditions for incompatible skin warnings

https://gerrit.wikimedia.org/r/819543

Jdlrobson renamed this task from AddImage plugin sometimes does not load to AddImage plugin sometimes does not load (Error: Your skin is incompatible with VisualEditor).Aug 6 2022, 10:32 AM
Jdlrobson added a subscriber: Jdlrobson.

Hey all, coming here from T314171. Web team is a bit confued about what's happening here and how we can help as we're getting regular email alerts for client errors now at a level that meets https://wikitech.wikimedia.org/wiki/Deployments/Holding_the_train#Issues_that_hold_the_train
https://grafana.wikimedia.org/d/000000566/overview?orgId=1&viewPanel=16&from=now-90d&to=now
It's taken us from 2k errors an hour to 25k errors an hour. Is this going to grow, or is the expectation that this is going to drop shortly due to cached pages, or is a fix needed? The incompatible error is for both Vector and Vector 2022 skins.

I understand this might not impact user experience (@matmarex said so), but I want to understand what's going on here, and make sure it gets addressed - is this a bug we've introduced, or are we debugging something? @Tgr on Slack said that something went wrong with the train deployment but it should be fixed so I'm a bit confused about the current state of this bug and who owns it. Is it Growth team, web team or editing team?

The log spike corresponds to the logging code (rEVED591796df12d4: Log incompatible skin warnings) reaching enwiki. The actual bug (if it is indeed a bug) was probably around for a long time, we just did not log it before. The train deployment issues were apparently unrelated.

The user impact is that VE does not load - question is, is that happening in a situation where it should load? (Could be cause by something like page protection, where not loading is expected.) I assume if there was significant real user impact, we'd have heard of that already.

Given the error volume and that it often happens on non-mainspace pages, I don't think this is related to Growth features (or at least those aren't the only source).

I've opened T314948 to track the need for filtering out anything not in the main channel.

FWIW I can easily reproduce this error in an incognito window on https://en.wikipedia.org/wiki/Fritz_Scheyhing and https://en.wikipedia.org/wiki/File:SOB_RABe_526_105_Traverso_in_Kreuzlingen.jpg (Vector skin)

I think it's mostly happening on pages that don't exist and file pages ?

FWIW I can easily reproduce this error in an incognito window on https://en.wikipedia.org/wiki/Fritz_Scheyhing and https://en.wikipedia.org/wiki/File:SOB_RABe_526_105_Traverso_in_Kreuzlingen.jpg (Vector skin)

I think it's mostly happening on pages that don't exist and file pages ?

FWIW Jon filed T314952: Misleading message shows in skins where VE is compatible but the page because of its state isn't ["Incompatible skin" / "Incompatible with VisualEditor"] about that (thanks!). It seems to account for most of these errors.

I think it's the other way around: the frequent false positives made the logging useless for this task, but now that they are removed, we can look at whether / why this error happens on Growth task pages (where the page should be editable so T314952 shouldn't happen - although there are probably edge cases like page protection).

rEVEDc697a6d2dac1: Do not show incompatible skin warning when page is not editable has been in production for two weeks and rEVEDe763f9d2f259: Error logging: Provide additional debugging context for one week so re-checking.

Seems to produce about 30-40 errors per hour at peak time, with Incompatible with VisualEditor: 1-0-1-1-0 which means init.isVisualAvailable, pageCanLoadEditor and pageIsProbablyEditable are true, init.isWikitextAvailable and requiredSkinElements are false. Seems to come from a fairly random assortment of wikis, and I don't see anything special about the pages on which it happens. Could it be some kind of race condition with the check running before the skin element is reliably there? Or some very widely used gagdet?

I've seen this twice in the last two days on cswiki using Firefox Nightly (106). If there's anything you'd like me to note down or experiment with, please let me know.

@kostajh if you see it again could you take a dump of the page HTML at the time (e.g.document.documentElement.innerHTML?

We should re-check the logs after gerrit 852309 is in production (thanks for looking into the issue @Jdlrobson!).

We should re-check the logs after gerrit 852309 is in production (thanks for looking into the issue @Jdlrobson!).

It's in production, so we should check the logs again.

It's in production, so we should check the logs again.

It will be deployed on Thursday, there was no train last week.

The logs stop at 23:00 UTC, which matches the deploy timing. With 0 events in the last 8 hours, I think we can consider this resolved.

rEVED282d075e0cf5: Don't log errors due to missing edit buttons silences the error if the edit button is not there, and we know that error scenario is happening regularly, so in theory some of it can be relevant to us and/or related to the original bug report, but we didn't find any issue with the code, and the logged URLs were not Growth-specific (most users aren't even logged in). I don't think this is worth investigating further unless we encounter it again directly.

Hmm, I still see this error semi-regularly in my local environment, but unfortunately have no idea how to consistently reproduce it. But if we don't see the logs in production, then I guess it is not worth troubling about.

Note: a warning will still show up in the console, but we don't log an error if no edit buttons are displayed in the page (as there's nothing we can do in this case). If you are seeing this locally it would be really helpful when it next happens to get a dump of the HTML and in particular a screenshot of what the edit buttons look like.