| Lucas_Werkmeister_WMDE | |
| Sep 24 2018, 8:02 PM |
| F26197719: Screenshot 2018-09-25 at 15.39.10.png | |
| Sep 25 2018, 1:43 PM |
| F26197730: Screenshot 2018-09-25 at 15.39.32.png | |
| Sep 25 2018, 1:43 PM |
| F26189270: Dn3br5SXgAELoHu.jpg:large.jpeg | |
| Sep 24 2018, 8:02 PM |
Sometimes, when attempting to add another value to an entity, the UI presents an input for a property ID, as if one had started to add a new statement, instead of just an input for the value.
I haven’t seen this myself yet, but it was reported by @Magnus here and confirmed by @agray and by @Harmonia_Amanda in the replies. According to Andrew, it “went away after a few refreshes“, and Harmonia suspects that “it’s when [you] do too many edits in too little time”.
Can confirm that my experience (probably on ~20 Sept if that helps narrow it down; Firefox 62 under Ubuntu) was as Magnus describes it. It happened on one or two pages; I haven't had it happen since and assumed it was some weird local browser issue so didn't file a bug for it.
Wikidata moved from 1.32.0-wmf.20 to 1.32.0-wmf.22 on September 19th, sounds like it could be a bug in that window. But I’m not seeing anything especially suspicious in the git log.
Hitting "Random item", I can reproduce the effect on roughly 1 in 3 pages. On any given item page, this effect shows either for no statement, or for all of them.
No error messages in the JS console on affected pages, only the following warnings (probably unrelated):
JQMIGRATE: Migrate is installed with logging active, version 3.0.1 load.php:141:149 This page is using the deprecated ResourceLoader module "jquery.jStorage". Please use "mediawiki.storage" instead. load.php:720:947 This page is using the deprecated ResourceLoader module "jquery.ui.position". load.php:77:291 This page is using the deprecated ResourceLoader module "jquery.ui.widget". load.php:108:942 This page is using the deprecated ResourceLoader module "jquery.tipsy". load.php:761:171 This page is using the deprecated ResourceLoader module "jquery.ui.core". Please use OOUI instead. load.php:20:84 JQMIGRATE: jQuery.expr[':'] is deprecated; use jQuery.expr.pseudos load.php:141:731 Your skin is incompatible with VisualEditor. See <https://www.mediawiki.org/wiki/VisualEditor/Skin_requirements> for the requirements. load.php:662:737 JQMIGRATE: jQuery.fn.bind() is deprecated load.php:141:731 JQMIGRATE: jQuery.fn.unbind() is deprecated load.php:141:731 JQMIGRATE: jQuery.fn.offset() requires an element connected to a document load.php:141:731 Use of "wgNamespaceNumber" is deprecated. Use mw.config instead. load.php:4:719 Use of "wgUserLanguage" is deprecated. Use mw.config instead. load.php:4:719 JQMIGRATE: jQuery.fn.delegate() is deprecated load.php:141:731 JQMIGRATE: jQuery.fn.offset() requires a valid DOM element load.php:141:731 This site appears to use a scroll-linked positioning effect. This may not work well with asynchronous panning; see https://developer.mozilla.org/docs/Mozilla/Performance/ScrollLinkedEffects for further details and to join the discussion on related tools and features!
The effect is persistent on specific items, e.g. https://www.wikidata.org/wiki/Q29201051
It happens on that item after reload, even after flushing the browser cache.
Confirmed in Firefox 63b6/Mac.
Happens to me on https://www.wikidata.org/wiki/Q29201051 even after I logged out and cleared the browser cache.
Can confirm I've just had it on https://www.wikidata.org/wiki/Q29201051 as well.
I get it on other items in the same browser session (https://www.wikidata.org/wiki/Q211775; https://www.wikidata.org/wiki/Q904305) but not others (https://www.wikidata.org/wiki/Q287; https://www.wikidata.org/wiki/Q10387684).
The effect seems to persist on reloading the pages.
(Update: now replicated on Chrome 69, Firefox 60, and IE 11 under Windows 10 - all logged out so shouldn't be any script/gadget issues. Q29201051 reliably triggers the odd behaviour; Q10387684 does not)
Haven't encountered this so far using the same configuration as Magnus. Maybe lists of enabled gadgets would be nice to have? Already checked common.js/global.js files of the listed users.
@Sjoerddebruin: Happens logged out as well, browser cache cleared, so no scripts/gadgets.
I’m able to reproduce this on Q29201051, thank you. It happens on any of the existing statements.
The entity data (via the wikibase.entityPage.entityLoaded hook) looks sane, and when I tried importing the entity into a local wiki via WikibaseImport, the error didn’t happen there.
I can also confirm that checking random items shows the bug fairly frequently (though it feels like less than 1 in 3 to me, but I haven’t counted), so raising priority for now.
I notice that the random items where I was able to reproduce this (1, 2, 3, 4, 5) have all been edited this month, but I’m not sure if that’s related: some of the random items I found where the bug did not happen had also been edited in that period.
Purging the page does not remove the glitch (tested on item 5 above).
I have my suspicions that this may be due to work done on: https://phabricator.wikimedia.org/T196226
So Q29201051 is no longer a test item since I edited it to test something: proceeding to add a statement, with a different property, will succeed; the statement will initially be in the wrong statement group, but after a page reload it will look as normal.
Also, it looks like I did my earlier test incorrectly, because now it appears that purging the page does fix the glitch. (Keeping the UBN though since this happens so commonly.)
It seems like this could be due to current JavaScript being incompatible with old, cached HTML. A simple way to fix that would be to purge all caches and drop all the old, cached HTML (e. g. increment the cache epoch); we should check with Ops if that’s acceptable or if we need a cleverer solution.
I'm pretty sure this has been introduced in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/460379
A data-attribute got introduced to store the statement group's property id which was previously stored in the html id attribute. If the HTML is outdated and doesn't contain the data attribute, the statement group doesn't know which property it belongs to and goes on to behave like a new statement.
DOM of a statement group of a buggy item
DOM of a statement group of a healthy item
Not the data-property-id attribute.
Change 462728 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[operations/mediawiki-config@master] Invalidate wikidatawiki cache with wgCacheEpoch
This is another case of this HTML not being in sync with the JS; seems that we need a way to at least predict this and do the invalidation but ideally have it automatic.
I'll leave this assigned to me as I'll look to get the cache epoch bump deployed once checking with SRE and Performance-Team .
Change 462864 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[operations/mediawiki-config@master] Set testwikidatawiki CacheEpoch to 2018-09-19
Change 462865 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[operations/mediawiki-config@master] Set wikidatawiki CacheEpoch to 2018-09-03
Change 462866 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[operations/mediawiki-config@master] Set wikidatawiki CacheEpoch to 2018-09-10
Change 462867 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[operations/mediawiki-config@master] Set wikidatawiki CacheEpoch to 2018-09-15
Change 462864 merged by jenkins-bot:
[operations/mediawiki-config@master] Set testwikidatawiki CacheEpoch to 2018-09-19
Mentioned in SAL (#wikimedia-operations) [2018-09-26T07:48:55Z] <addshore@deploy1001> Synchronized wmf-config/InitialiseSettings.php: [[gerrit:462864|Set testwikidatawiki CacheEpoch to 2018-09-19]] T205330 (duration: 00m 56s)
Change 463202 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[operations/mediawiki-config@master] RejectParserCacheValue Hook to purge wikidatawiki to 2018-09-15
Change 463203 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[operations/mediawiki-config@master] RejectParserCacheValue Hook to purge wikidatawiki to 2018-09-06
Change 463203 merged by jenkins-bot:
[operations/mediawiki-config@master] RejectParserCacheValue Hook to purge wikidatawiki to 2018-09-06
Change 463207 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[operations/mediawiki-config@master] RejectParserCacheValue Hook to purge wikidatawiki to 2018-09-08
Change 463207 merged by jenkins-bot:
[operations/mediawiki-config@master] RejectParserCacheValue Hook to purge wikidatawiki to 2018-09-08
Change 463208 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[operations/mediawiki-config@master] RejectParserCacheValue Hook to purge wikidatawiki to 2018-09-12
Change 463208 merged by jenkins-bot:
[operations/mediawiki-config@master] RejectParserCacheValue Hook to purge wikidatawiki to 2018-09-12
Change 463202 merged by jenkins-bot:
[operations/mediawiki-config@master] RejectParserCacheValue Hook to purge wikidatawiki to 2018-09-15
Change 463221 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[operations/mediawiki-config@master] RejectParserCacheValue Hook to purge wikidatawiki to 2018-09-19
Change 463221 merged by jenkins-bot:
[operations/mediawiki-config@master] RejectParserCacheValue Hook to purge wikidatawiki to 2018-09-19
We've now invalidated the cache for all pages in the parser cache before the train was deployed last week so it should now be fixed for logged in users. There is still a possibility that un-logged in users will see something stale from the Varnish cache
the varnished cached pages would expire 14 days after the deployment that caused an issue, if they aren't purged for another reason before hand
Change 467913 had a related patch set uploaded (by Addshore; owner: Addshore):
[operations/mediawiki-config@master] Remove Wikidaat RejectParserCacheValue hook
Change 467913 merged by jenkins-bot:
[operations/mediawiki-config@master] Remove Wikidata RejectParserCacheValue hook
Mentioned in SAL (#wikimedia-operations) [2018-10-17T11:15:13Z] <addshore@deploy1001> Synchronized wmf-config/CommonSettings.php: SWAT: T205611 T205330 Remove Wikidata RejectParserCacheValue hook [[gerrit:467913]] (duration: 00m 56s)